2019, the best way to learn CPU on FPGA - Page 1
Forum section: electronics / general

author: richardman
author_rank: Frequent Contributor
timestamp: August 17, 2019, 12:08:38 am
content: What's the current relatively inexpensive state of the art way to design FPGA CPU? I know a lot about instruction set architectures and many instruction sets, including weird ones like the Mill, and I know A LOT about compilers/linkers/etc. My goal is to play with VLIW CPU design because... why not? (I wrote the first Itanium code generator at HP)Inexpensive means under $1000, including any software licenses. This is strictly hobbyist level stuff.Also any particularly good web sites, books, etc.? I know about opencores...Thanks

author: rstofer
author_rank: Super Contributor
timestamp: August 17, 2019, 01:02:33 am
content: Google for the LC3 or LC3b project. It is a modern yet simple RISC project, There is a complete description, state table and microcode worksheet.I built mine using a Digilent Nexys4 DDR board, since superceeded. The project has a textbook, assembler and C compiler.It’s a common university project.

author: colorado.rob
author_rank: Frequent Contributor
timestamp: August 17, 2019, 02:59:38 am
content: A Pynq-Z2 is $120 and is usable with the free Vivado Webpack from Xilinx. It will easily fit a number of RISC-V implementations. You don't have to spend anywhere close to $1000. I don't know of any VLIW cores. Certainly nothing modern. It's considered a dead end architecture at this point.If you want to spend $1000, theZCU104is where I'd go.The hot ISA right now is RISC-V. Lots of good talks about it on YouTube. Lots of open implementations on GitHub.

author: richardman
author_rank: Frequent Contributor
timestamp: August 17, 2019, 04:27:51 am
content: Yea, I know VLIW is "dead" (but not quite). It's just for playing around. Thanks

author: hamster_nz
author_rank: Super Contributor
timestamp: August 17, 2019, 04:56:29 am
content: If you want to hit your budget, thenhttps://store.digilentinc.com/genesys-2-kintex-7-fpga-development-board/is pretty goid. But the Nexys boards will also be a good starting place.If you do go for the Gensys2, just make sure you plan some way to use your node locked license the way you want.Running Linux and using ethtool to change the MAC address of your onboard NIC works for me.Also note that you will get version locked to a major release too.Edit: that ZUC104 looks pretty nice too. But I wonder how many interfaces are any available to the CPU cores...

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 17, 2019, 02:37:57 pm
content: I haven't looked very hard, but didn't find any VLIW core available to play with, so you're pretty much on your own here.I guess for a VLIW architecture, you'll need a decently-sized FPGA. I guess an Artix-7 50T or 100T would be more than adequate to begin with. There's the Nexys 4 board. For something cheaper, you could even consider a Mimas A7:https://numato.com/product/mimas-a7-artix-7-fpga-development-board-with-ddr-sdram-and-gigabit-ethernetQuite a lot you can do with this already.

author: rstofer
author_rank: Super Contributor
timestamp: August 17, 2019, 06:51:47 pm
content: Microcode is a form of VLIW. I don't know if they are still in use but 'meta-assemblers' were popular back in the '80s to handle the very large instruction word. I never had one and that limited what I could do with the AM2900 series without a struggle.The LC3 project is, in textbook form, microcoded. There are on the order of 64 states (not all used but 6 bits allocated for addressing the microcode store) and the worksheet allows the developer to put the various required 1s and 0s in the various fields.I didn't microcode mine, I just implemented the state chart with a case statementThe state chart is on page 9https://www.seas.upenn.edu/~cit595/cit595s10/lectures/d&c.pdfThe microcode worksheet is at the lower right of the last page:http://people.cs.georgetown.edu/~squier/Teaching/HardwareFundamentals/LC3-trunk/docs/LC3-uArch-PPappendC.pdfThe idea of the meta-assembler was to be able to name the fields in a very wide word and provide default values for each. In this way, only the changes at each state had to be assembled and stuffed into the output field.IBM invented the 8" floppy in '67 to store microcode for the 360 and 370 series computers. We've come a long way in 50 years.ETA: Note the number of universities using this project! Georgetown, UPenn, and if you Google around, many others.

author: tolpe
author_rank: Newbie
timestamp: August 25, 2019, 08:30:20 am
content: Actually we use quite a bit of VLIW microcode in our designs. It's just a bit of another way to design logic in a flexible way.For example, take a Discrete Cosine Transformation occuring in a JPEG compressor, for example. You can either hard code the pipeline or invent a fitting custom VLIW set which defines something like a program in a hard loop for the fetch, ALU, data routing and write stages.And when embedding this into a custom DSP unit, this would be your microcode that you download into the distributed RAM controlling the algorithm. So you can do forward/inverse transform on the fly, for example, by swapping out the microcode blob from the main CPU.A colleague has also experimented with VLIW in RISC and stack machine designs where an opcode (or sequence) is translated into VLIW in one pipeline stage. When changing the instruction set, you change just this translator stage.So I think it's a good idea to play with it, it seems that little is practised/taught like this at least here in Europe. Or people are just very silent about microcode approaches, due to patent situations, I really don't know.You might remember Transmeta, they didn't make it economically, but their approach was ingenious from a technical perspective.To start with, you might not need to worry about hardware, there are free simulators around (icarus verilog, ghdl, python myhdl). I personally would use myhdl for prototyping and verification.

author: tggzzz
author_rank: Super Contributor
timestamp: August 25, 2019, 09:27:12 am
content: Quote from: richardman on August 17, 2019, 04:27:51 amWhy not consider a different challenge?One is to get goodhardrealtime performance, where the input to processing latency to output latency isguaranteedby design, not by testing and hoping you have spotted the worst case.That's non-trivial since it requires good hardware/software codesign and integration. The hardware must be relatively simple and tractable (no interrupts, no caches), and you already have some software too experience.I know of one and only one commercial design that achieves those goals. It would be good to see others.

author: hamster_nz
author_rank: Super Contributor
timestamp: August 25, 2019, 10:40:36 am
content: I've followed up on a little here with an experiment on a Basys3 (Xilinx Artix 7) dev board.I've created a design that is a three bit Gray counter, that outputs to a PMOD port (pins 1-3) , inputs it from the same PMOD (pins 7-9) port an latches it the next cycle, and I've put 0.1" breadboard jumpers between the pins.The idea being that when the clock is slow the latched value will be the expected value. However, once the clock gets fast enough it will read the prior value due to propagation delay in the input and output buffers.At 100MHz (10ns) everything agrees, at 105MHz (9.5ns) things are a bit patchy, and at 111 MHz (9 ns) the expected and latched value always differs.There are also some other little minor details that impact on things, like the PMOD port has 200 ohm series resistors and ESD protection, but I still feel it is an illustrative test that when running at 100MHz there is nowhere near 10ns for async SDRAM access.I've also set signal attributes to ensure that the values are registered in the I/O block (IOB) and not within the fabric for minimal delay, and verified that they have have been implemented as designed.So my best guess would be that if you were trying to latching the output of 10ns SRAM on the falling edge it would be workable only up to around 25MHz, and maybe with a a good tailwind and some luck might achieve a workable design at 30MHz. But this relies on a lot of things like getting the SRAM control, address and signals to be registered in the IOBs, which is really unlikely unless carefully designed.Code:library IEEE;use IEEE.STD_LOGIC_1164.ALL;Library UNISIM;use UNISIM.vcomponents.all;entity loopback isPort ( clk100 : in STD_LOGIC;outputs : out STD_LOGIC_VECTOR (2 downto 0) := "000";inputs : in STD_LOGIC_VECTOR (2 downto 0);success_led : out STD_LOGIC := '0');end loopback;architecture Behavioral of loopback issignal latched : std_logic_vector(2 downto 0) := "000";signal state : std_logic_vector(2 downto 0) := "000";signal last_state : std_logic_vector(2 downto 0) := "000";signal last_last_state : std_logic_vector(2 downto 0) := "000"; -- should match latchedsignal clk,clkfb : std_logic;attribute IOB : string;attribute IOB of outputs : signal is "TRUE";attribute IOB of latched : signal is "TRUE";beginprocess(clk)beginif rising_edge(clk) thenlatched <= inputs;end if;end process;process(clk)beginif rising_edge(clk) thenif latched = last_last_state thensuccess_led <= '1';elsesuccess_led <= '0';end if;last_last_state <= last_state;last_state <= state;outputs <= state;case state iswhen "000" => state <= "001";when "001" => state <= "011";when "011" => state <= "010";when "010" => state <= "110";when "110" => state <= "111";when "111" => state <= "101";when "101" => state <= "100";when "100" => state <= "000";when others => state <= "000";end case;end if;end process;MMCME2_BASE_inst : MMCME2_BASEgeneric map (BANDWIDTH => "OPTIMIZED",CLKFBOUT_MULT_F => 10.0,CLKFBOUT_PHASE => 0.0,CLKIN1_PERIOD => 10.0,CLKOUT0_DIVIDE_F => 9.0,CLKOUT1_DIVIDE => 10, CLKOUT2_DIVIDE => 10, CLKOUT3_DIVIDE => 10,CLKOUT4_DIVIDE => 10, CLKOUT5_DIVIDE => 10, CLKOUT6_DIVIDE => 10,CLKOUT0_DUTY_CYCLE => 0.5,CLKOUT1_DUTY_CYCLE => 0.5, CLKOUT2_DUTY_CYCLE => 0.5, CLKOUT3_DUTY_CYCLE => 0.5,CLKOUT4_DUTY_CYCLE => 0.5, CLKOUT5_DUTY_CYCLE => 0.5, CLKOUT6_DUTY_CYCLE => 0.5,CLKOUT0_PHASE => 0.0, CLKOUT1_PHASE => 0.0, CLKOUT2_PHASE => 0.0,CLKOUT3_PHASE => 0.0, CLKOUT4_PHASE => 0.0, CLKOUT5_PHASE => 0.0,CLKOUT6_PHASE => 0.0,CLKOUT4_CASCADE => FALSE,DIVCLK_DIVIDE => 1,REF_JITTER1 => 0.0,STARTUP_WAIT => FALSE)port map (CLKIN1 => CLK100,CLKOUT0 => clk, CLKOUT0B =>open,CLKOUT1 => open, CLKOUT1B => open,CLKOUT2 => open, CLKOUT2B => open,CLKOUT3 => open, CLKOUT3B => open,CLKOUT4 => open,CLKOUT5 => open,CLKOUT6 => open,CLKFBOUT => clkfb, CLKFBOUTB => open,CLKFBIN => clkfb,LOCKED => open, PWRDWN => '0',RST => '0');end Behavioral;Code:## Clock signalset_property PACKAGE_PIN W5 [get_ports clk100]set_property IOSTANDARD LVCMOS33 [get_ports clk100]create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports clk100]## LEDsset_property PACKAGE_PIN U16 [get_ports {success_led}]set_property IOSTANDARD LVCMOS33 [get_ports {success_led}]##Pmod Header JA##Sch name = JA1set_property PACKAGE_PIN J1 [get_ports {outputs}]set_property IOSTANDARD LVCMOS33 [get_ports {outputs}]#Sch name = JA2set_property PACKAGE_PIN L2 [get_ports {outputs}]set_property IOSTANDARD LVCMOS33 [get_ports {outputs}]#Sch name = JA3set_property PACKAGE_PIN J2 [get_ports {outputs}]set_property IOSTANDARD LVCMOS33 [get_ports {outputs}]##Sch name = JA7set_property PACKAGE_PIN H1 [get_ports {inputs}]set_property IOSTANDARD LVCMOS33 [get_ports {inputs}]##Sch name = JA8set_property PACKAGE_PIN K2 [get_ports {inputs}]set_property IOSTANDARD LVCMOS33 [get_ports {inputs}]##Sch name = JA9set_property PACKAGE_PIN H2 [get_ports {inputs}]set_property IOSTANDARD LVCMOS33 [get_ports {inputs}]

author: brucehoult
author_rank: Super Contributor
timestamp: August 27, 2019, 06:12:14 am
content: Quote from: richardman on August 17, 2019, 12:08:38 amA small RISC-V (RV32I) core can be done in around 300 6-LUTs, a pretty full featured one 1500 to 3000 e.g. PicoRV32 depending on config. IBM's just released "Microwatt" POWER FPGA core is 11k LUTs.Xilinx boards with 35k, 50k, 100k LUTs are available for $100 to $250.So you can get pretty major CPUs into a cheap FPGA. We get a full SiFive U74 (dual issue in order, DP FPU, MMU, caches) into an Arty 100T, but only one core.Xilinx Vivado is .. "professional". Powerful but annoying. The open-source toolchain using yosys, nextpnr supports only a few FPGAs right now, mostly smaller Lattice iCE40 ones (but big enough for a smallish CPU). They are busy reverse-engineering others and had some success with Xilinx ones recently.

author: laugensalm
author_rank: Regular Contributor
timestamp: August 27, 2019, 07:56:55 am
content: Hi,I personally found the various MIPS architectures most interesting to start with (I'd consider RISC-V a cleaned up derivative, with the big difference of the branch delay slot). In fact, uBlaze, NIOS, lm32, etc. go down a similar path. If you'd want to go really low end, the ZPU architecture, a stack machine hybrid, is also very interesting, as it hits the record with compactness (in logic and opcode density). Question is always how you want to program your new CPU. This is the biggest task, in fact: developing a good assembler/C compiler/debugger for a new architecture. So I'd start from a known architecture with existing tool chain and enhance it by whatever trickery you can think of. If your instruction set is limited, you can use a PC address bit for opcode enhancement and jump into 'emulation microcode area' as the ZPU is practicing it.If you're a VHDL guy, you might play with this docker setup:https://hub.docker.com/r/hackfin/masocist/It includes all necessary tools (GHDL simulator, GCC) and a linux'ish configuration to select platform, CPU arch, etc. The default preset is a neo430 (msp430 clone) spitting out some stuff over a virtual UART console.

author: brucehoult
author_rank: Super Contributor
timestamp: August 27, 2019, 08:32:03 am
content: Quote from: laugensalm on August 27, 2019, 07:56:55 amNot to pick on your in particular, but why is everyone recommending their favourite CPU architecture when the OP specifically states that he wants to play with his own VLIW ISA?Existing soft cores would I expect be of interest in showing him how to get started with tools etc, but I expect it hardly matters which one.

author: laugensalm
author_rank: Regular Contributor
timestamp: August 27, 2019, 11:29:23 am
content: Quote from: brucehoult on August 27, 2019, 08:32:03 amI think you're misreading. I'm not recommending, I just think MIPS is among the best studied and documented with respect to VLIW tricks and extensions. Likewise, one can start with extending RISC-V with vector ops, of course. I don't see a big difference.Quote from: brucehoult on August 27, 2019, 08:32:03 amI think it does. I've tried a few more cores which weren't that easy to extend, but I admit I had some 'economical' pressure, too.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: August 27, 2019, 11:38:15 am
content: Quote from: brucehoult on August 27, 2019, 06:12:14 amIf you want to go really cheap there are spartan 6 lx16 boards with external RAM available in the $17 -25 dollar range from ali-express (various vendors)https://www.aliexpress.com/item/1000006703110.html?spm=a2g0o.detail.1000014.15.71db4f18ysZ7KH&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.13338.128206.0&scm_id=1007.13338.128206.0&scm-url=1007.13338.128206.0&pvid=78a2484b-457a-4127-b1f3-29668f40fef6https://www.aliexpress.com/item/1000006622145.html?spm=a2g0o.detail.1000060.1.7a62598afx6UNB&gps-id=pcDetailBottomMoreThisSeller&scm=1007.13339.139618.0&scm_id=1007.13339.139618.0&scm-url=1007.13339.139618.0&pvid=ebc7ca34-7654-43ad-b1d6-726bcaa0cd8eThey however require older ise webpack.The more experienced people can advise suitability. These boards do not have the ethernet or seven segment displays and other bling that people seem to prefer. I actually like this simple type better, but I am not interested in softcores or making my own ISA so your mileage can vary.personally I would go with one of the digilent artix 7 suggestions.

author: agehall
author_rank: Frequent Contributor
timestamp: August 27, 2019, 11:45:37 am
content: Quote from: chickenHeadKnob on August 27, 2019, 11:38:15 amBoth good and bad imho. ISE is dead - we just have to face it that Vivado is the way forward. Vivado is a beast. ISE was dead simple, anyone could use it. Vivado (at least to me) is complicated as ****. I'm trying the best I can to learn the ways of it but it takes a lot of time and effort.If you are just starting out and want something easy and just play around with FPGA and CPLD, ISE is not a bad thing imho. But if you want to have a path to the future with Xilinx, you will have to get to Vivado at some point.

author: TK
author_rank: Super Contributor
timestamp: August 27, 2019, 12:35:14 pm
content: RISC-V is an open source RISC CPU and there are cheap FPGA boards coming from China to experiment like the Sipeed TANG with ANLOGIC FPGA

author: asmi
author_rank: Super Contributor
timestamp: August 27, 2019, 12:47:23 pm
content: Quote from: agehall on August 27, 2019, 11:45:37 amI disagree. For me it is the absolute opposite - Vivado is waaaay simpler and easier to use than ISE once you wrap your head around diagrams and IPI. In Vivado I can design an entire embedded system with softcore, DDR3 controller and crap ton of other peripherals without writing a single line of HDL code, or I can do the same but add some of my modules into the system just as easily. Try that in ISE!Also Vivado supports SystemVerilog which is my HDL of choice so obviously that't crucial for me.

author: agehall
author_rank: Frequent Contributor
timestamp: August 27, 2019, 01:16:12 pm
content: You have a good point there asmi. But just looking at the toolchain, I'd say Vivado is much more difficult to understand how to put to correct use than ISE.

author: tggzzz
author_rank: Super Contributor
timestamp: August 27, 2019, 01:22:21 pm
content: As with any software project I like to keep my source files (including relevant config files) in a repository, so I can revert when I decide I've gone down a blind alley.With Vivado you end up with an enormous directory tree full ofstuff. Is there any reliable definition of which subset of those files I should put in a repository in order to be able to reconsititue my design?The last time I looked, a few years ago, nobody could tell me.

author: asmi
author_rank: Super Contributor
timestamp: August 27, 2019, 01:32:01 pm
content: Quote from: agehall on August 27, 2019, 01:16:12 pmWhat's so difficult about that compared to ISE? If you ignore IPI (which doesn't exist in ISE if we ignore PlanAhead or whatever it was called, which as I understand was where Vivado came from eventually), the workflow is pretty much the same - you create HDL source files, constraints and sim-only files, run behavioral simulations, once your stuff works, you push "Implement" and see if timing is closed. If it is, you press "Generate Bitstream" and then open HW manager to program the FPGA. What about that flow is fundamentally difficult compared to ISE?

author: asmi
author_rank: Super Contributor
timestamp: August 27, 2019, 01:54:45 pm
content: Quote from: tggzzz on August 27, 2019, 01:22:21 pmThere is an appnote for that:https://www.xilinx.com/support/documentation/application_notes/xapp1165.pdfI think it's enough to store <project_name>.srcs and <project_name>.sdk folders. If you use IPI, Vivado automatically generates tcl file each time you save diagram that can be used to recreate it, so if you're concerned with your repo size, you can store just that script. You can also generate such script at any time by using write_bd_tcl command. I use it a lot to create a "boilerplate" design to use as a base for new projects so I don't have to repeat the same steps (like adding Microblaze, configuring MIG, debug-uart, etc.).Alternatively, you can store your HDL files anywhere outside Vivado project folder, link them to your Vivado project and version them like you would any folder. write_bg_tcl command would be useful here if you use IPI and want ability to restore diagram(s) as well.

author: tggzzz
author_rank: Super Contributor
timestamp: August 27, 2019, 02:26:35 pm
content: Quote from: asmi on August 27, 2019, 01:54:45 pmThanks. Your "I think..." was typical of the responses I received previously, and doesn't inspire confidence that Xilinx had thought through the issueAre all the presumptions in that 7 year old app note still valid? Tools do change!The AppNote's summary is "...The recommended methodology is to use the Vivado Design Suite Manage IP feature for IP management, keep design sources as remote files, and use Tool Command Language (Tcl) scripts to manage design sources, design runs, and project creation....".An example section in the body is "Changes made to the project interactively in the Vivado IDE must be written out to a new Tcl script using the write_project_tcl command. Use the merge function provided by the version control system to resolve the differences between the new script and the one in the repository."That soundsveryerror-prone/brittle and liable to have subtle failure modes that mayor may notbe visible when reverting. Ensuring you havecorrectlycapturedeverythingseems like a major task that has to be repeated at intervals.While TCL is't a bad starting point, the requirement to understand thesubtletiesof how their TCL extensions interact with a large, unknown directory tree is also sub-optimal.Nonetheless thatoldAppNotemaybe a suitable starting point.

author: agehall
author_rank: Frequent Contributor
timestamp: August 27, 2019, 02:40:13 pm
content: Quote from: asmi on August 27, 2019, 01:32:01 pmTo me, Vivado feels like a black hole in some ways. If you do super-simple stuff, it works just fine but as soon as I try to do something a bit more complicated (like creating an IP), I feel like I'm running into trouble right away. I just don't get the workflows and how it all comes together. With ISE everything just fell into place for me but it doesn't feel like that with Vivado.

author: asmi
author_rank: Super Contributor
timestamp: August 27, 2019, 02:58:53 pm
content: Quote from: agehall on August 27, 2019, 02:40:13 pmEvery time I read someone "feels" something about something my BS detector goes off. I can't argue with feelings - only with facts. And the fact is I've learnt the tool, so it can be done. Maybe you just didn't bother to learn the tool? There are tons of guides and tutorials covering just about any feature there is. That's how I learnt - read/watched tutorials + some practical experiments. And ISE was much harder for me to grasp - that's why I made an executive decision to stay away from it entirely and stick to 7 series. I still don't know if there is a way to build an AXI system in ISE without massive (and I meanmassive!) copy-paste to connect all buses together and hope that you didn't make any typos in the process. And timing constraints in ISE are just incomprehensible to me. I could perhaps invest a ton of time to figure them out, but that begs another question - what's the point to learn the system that is essentially on life support?

author: asmi
author_rank: Super Contributor
timestamp: August 27, 2019, 03:31:00 pm
content: Quote from: tggzzz on August 27, 2019, 02:26:35 pmI don't work for Xilinx, so I can't possibly know if they thought about this or not, but the presence of appnote suggests that they did at least at some level.Quote from: tggzzz on August 27, 2019, 02:26:35 pmWell nothing stops you from trying to see if that's the case.Quote from: tggzzz on August 27, 2019, 02:26:35 pmSorry but this part doesn't make sense to me. All VCS are able to restore files to any previous checkpoint without any merging. Merge is for different purpose entirely, and is absolutely not required to restore project to any previous state. I used to use old school zip for that in the past - and it worked just fine for the most part (only seeing "what changed" was a PITA).Quote from: tggzzz on August 27, 2019, 02:26:35 pmI just did the following:Took one of my IPI projects for upcoming board that I'm working on - it's a typical Microblaze system with 64bit CPU, MIG configured to work with 4Gbyte SODIMM and some peripherals like MDM and such. Then I zipped it up, deleted everything from it except the project file and folders *.srcs and *.sdk, and reopened the project. And it worked! I used 2019.1. If you want to reduce the amount of stuff that goes into repo and don't mind having to re-run synthesys after reverting, you can "Reset Output Products" before you put stuff into VCS.

author: agehall
author_rank: Frequent Contributor
timestamp: August 27, 2019, 05:00:31 pm
content: Quote from: asmi on August 27, 2019, 02:58:53 pmGood for you that you know the tool inside and out. My point is that it took me about 4h to learn how to use ISE and feel at home with it. With Vivado I've spent a lot more time than that and I'm still not comfortable with it.The problem with tutorials online is that they all tell slightly different stories and/or showcase only simple stuff. I've watched my fair share but I still don't feel comfortable with it. And I'm sorry you don't like feelings but there are feelings involved when it comes to picking an IDE. For example, I'm very much proficient in VI but I feel much more at home in Emacs. Is that objective? Heck no, but that is how I feel about it. At no point have I tried to argue that Vivado is bad or that I don't want to learn it - I'm just arguing that for some people (like me) it is much harder to learn it than it was learning ISE.

author: tggzzz
author_rank: Super Contributor
timestamp: August 27, 2019, 05:04:54 pm
content: Quote from: asmi on August 27, 2019, 03:31:00 pmAgreed, but my life is limitedQuoteI'm sure a VCS will cope with whatever text files you feed it. They are designed to do that, but there are limitations.The first issue is ensuring the files are textual - no problem for vhdl/verilog etc, but are all required files text? What about the "schematics" showing the interconnections between IP blocks, or the IP blocks themselves?Since Xilinx requires that you manually resolve the differences between some files, the second issue is ensuring the differences between the text files can be understood and resolved.The third issue is ensuring you have all the text files. That is even more problematic with a Zynq design, where there are many autogenerated files to enable the PL and PS subsystems to communicate with each other.Except for the PS<->PL interface files, I'm not concerned about the .c/.h/.py/etc files for the PS subsystem, handling them is standard with any repository.QuoteAnd what else would have had to include/exclude for a Zynq system?Don't forget that AppNote was written before Zynq devices were released, and makes no reference to them.

author: tggzzz
author_rank: Super Contributor
timestamp: August 27, 2019, 05:14:01 pm
content: Quote from: agehall on August 27, 2019, 05:00:31 pmI'm content that it would take significant time to know how to use Vivadocorrectlyfor Zynq systems. The problem domain is complex and the tools reflect that.I'm not content that I do not knowhowto determine that Iamusing it correctly.I'm especially not content with point-and-drool interfaces which hide so much that it is impossible to be sure you have got hold of the minimum necessaryautogeneratedfiles.Sure some of the the point-and-drool tutorials are pretty good, but they aren't sufficient. I'd like to see a document stating "this step generates these files in that directory, and you must preserve them, but all files in other directories will be automatically regenerated when you repeat the step".

author: asmi
author_rank: Super Contributor
timestamp: August 27, 2019, 05:19:22 pm
content: Quote from: agehall on August 27, 2019, 05:00:31 pmWell I can't do anything with "feelings", but if you have any specific questions regarding Vivado - feel free to ask. I'm far from being expert for it, but I know enough of it to create real projects that actually work, so I will do my best to help out. BTW I use VS Code as code editor because the one built into Vivado IMHO sucks

author: tggzzz
author_rank: Super Contributor
timestamp: August 27, 2019, 05:28:33 pm
content: Quote from: asmi on August 27, 2019, 05:19:22 pmDo any of your projects involve Zynq devices?Such projects are necessarily much more complex, but I'd like to see a definition of the points I made in earlier messages.

author: asmi
author_rank: Super Contributor
timestamp: August 27, 2019, 06:41:35 pm
content: Quote from: tggzzz on August 27, 2019, 05:14:01 pmThe truth is - IPI doesn't actually hide anything - all is in the openIt just automates tedious connections between modules (you see a single AXI bus connection instead of 50+ signals that belong to that bus) as well as configuring IP settings. But ultimately it's little more that HDL code generator - you can see that generated HDL in "synth" subfolder of your diagram.Quote from: tggzzz on August 27, 2019, 05:28:33 pmNo, but I have some test projects that use Zynq. And as far as I can tell, there is nothing particularly complex about Zynq - it's treated just like any other IP in IPI. And it's not the most complex IP settings-wise (MIG is much more complicated and even uses it's own project files). And all IP settings are stored in *.hwh and the actual .bd file for the diagram (which are text-based), and all these settings are also present in autogenerated tcl file for the diagram, which you can use to re-create it. Also I remember reading that Vivado developers made a concerted effort to only use text-based files specifically to make using VCS easier, and as far as I can tell, most files inside *.srcs folder are infact text-based (except for some simulation files and *.hwdef files).If you want to test this theory - perform these steps:1. Open any Zynq-based project you've got, then open the system diagram.2. Execute command: write_bd_tcl -include_layout <path/script_file_name>.tcl Make sure you use forward slashes even if you're running Vivado on Windows.3. Create brand new empty project that uses the same device/devboard.4. Execute this command: source <path/script_file_name>.tcl.It should re-create the diagram you had in the original project with all settings exactly like ones you had in original diagram. If it did - run synth&implementation to see if it works.This should not take a lot of time, and you will know for sure if this script is all that's required.BTW in case you didn't know, you can export diagram into PDF using this command: write_bd_layout -format pdf <file_name>.pdf It's great for documentation purposes!

author: tggzzz
author_rank: Super Contributor
timestamp: August 27, 2019, 07:04:25 pm
content: Quote from: asmi on August 27, 2019, 06:41:35 pmSeems very sensible.Now, the pretty picture showing what is connected to what is the obvious source file, since I created the links.Where is that information stored, and can it reasonably be saved in a repository?.That'sthe kind of information that ought to be statedexplicitlysomewhere or other.After I am shown such explicit statements, my questions crumble into insignificance.QuoteI have no reason to doubt you, but unless Xilinx states that subset of the files is necessaryand sufficient, it is a big leap of faith that I haven't missed something subtle.

author: asmi
author_rank: Super Contributor
timestamp: August 27, 2019, 07:37:19 pm
content: Quote from: tggzzz on August 27, 2019, 07:04:25 pmI told you where this information is stored in the previous post.Quote from: tggzzz on August 27, 2019, 07:04:25 pmIf you can't be bothered to find a solution nor to ask Xilinx - you always have an option of just saving "everything" - and that will work for sureI work on my projects on two computers, one of which doesn't have access to Internet (or any net for that matter), so I simply zip up the whole project and transfer it over every time I need to move project between computers. It works just fine.

author: brucehoult
author_rank: Super Contributor
timestamp: August 27, 2019, 07:52:29 pm
content: Quote from: TK on August 27, 2019, 12:35:14 pmRISC-V is an open source and patent and license-free instruction set definition. CPUs implementing the instruction set can be open source or closed source, free or commercial, as their designer wishes.The biggest reason to use it as a base for a custom CPU is that someone else already wrote the compilers, ported Linux and other software etc. It's rapidly getting to the point (not there yet, but will be soon) that the software ecosystem is better than everything except x86 and ARM.

author: agehall
author_rank: Frequent Contributor
timestamp: August 27, 2019, 09:03:57 pm
content: Quote from: asmi on August 27, 2019, 05:19:22 pmVery concrete question: Did you get syntax highlighting and linting working in VS Code? I tried Verilog HDL/SystemVerilog by mshr-h but I can't get it working. If you have a working setup (preferably under Windows) I'm very interested in knowing what you have found that works in VSC.

author: tggzzz
author_rank: Super Contributor
timestamp: August 27, 2019, 09:17:16 pm
content: Quote from: asmi on August 27, 2019, 07:37:19 pmAs far as I can see you told me a fewexperimentsI could do. That's rather different!QuoteA few years ago I did try,repeatedly, to find solid information from Xilinx and on the forums. The silence was deafening.As for saving the equivalent of .o and executable files in a repository, if that's a serious suggestion then you have abandoned making serious points.OTOH, I do recognise the value of containing each project in an independent VM, so that it can be modified/maintained in a few years time. But that's a completely different use-case, so completely different solutions are reasonable.

author: blacksheeplogic
author_rank: Frequent Contributor
timestamp: August 27, 2019, 10:14:10 pm
content: Quote from: tggzzz on August 27, 2019, 09:17:16 pmEither that or the same old generic 'community' suggestion not related to your actual problem.

author: asmi
author_rank: Super Contributor
timestamp: August 27, 2019, 10:20:16 pm
content: Quote from: agehall on August 27, 2019, 09:03:57 pmI tried out several extensions and finally settled on "SystemVerilog-1800-2012" by gvekony. I use SystemVerilog, so for me it's the best. I like that it contains code snippets for SV constucts like interface, function, task and so on.

author: tggzzz
author_rank: Super Contributor
timestamp: August 27, 2019, 10:22:10 pm
content: Quote from: blacksheeplogic on August 27, 2019, 10:14:10 pmI'm sorry, I don't understand what you are trying to say.

author: asmi
author_rank: Super Contributor
timestamp: August 27, 2019, 10:22:54 pm
content: Quote from: tggzzz on August 27, 2019, 09:17:16 pm"Those who want to solve a problem are looking for solutions, those who don't want to solve a problem are looking for excuses" (C) I have nothing more to add on this subject.

author: blacksheeplogic
author_rank: Frequent Contributor
timestamp: August 27, 2019, 10:37:40 pm
content: Quote from: tggzzz on August 27, 2019, 10:22:10 pmIf you can't find an app note or the information in the datasheet asking a question especially to the community forums is just more wasted time.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 28, 2019, 12:24:23 am
content: For the record, I just tried Vivado today. At the moment, I don't know whether I'm doing anything wrong, but it's just atrociously slow. Tried it on a project for an Artix 7 35T, so not that big either. The project is some example around a MIG block and tests with a DDR3 memory chip. The implementation phase took like almost 10 minutes. Is that normal?

author: asmi
author_rank: Super Contributor
timestamp: August 28, 2019, 03:46:41 am
content: Quote from: SiliconWizard on August 28, 2019, 12:24:23 amIt could be if this is the first run (when all OOC synthesis is performed) and/or you've got slower computer. OOC synthesis runs in parallel, so the more cores you've got, the faster it completes. But this is only for the first time, subsequent runs only re-synthesize components that were changed between runs. On my rather old 6/12 cores CPU basic 64bit Microblaze system with 4GByte SODIMM implemented on A100 runs for about 10 minutes for the first time, subsequent runs are about half of that (depending on what exactly was changed).

author: tggzzz
author_rank: Super Contributor
timestamp: August 28, 2019, 06:54:32 am
content: Quote from: blacksheeplogic on August 27, 2019, 10:37:40 pmNonsense.Firstly I may well have missed the relevant principles and/or app note.Secondly community forums often contain very useful information filling in the gaps between the information provided by a supplier.Naturally the former is preferable, but I'll accept the latter.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 28, 2019, 03:17:31 pm
content: Quote from: asmi on August 28, 2019, 03:46:41 amAlright...And nope the computer I tested it on is not slow. Core i7/5930K@4.4GHz, 64GB RAM, 2 SSDs...Yes I noted the first run is awfully slow, and then it gets faster... I understand the Artix 7 is more complex than a Spartan 6, but damn that's awfully slow compared to ISE...I even tested a very simple example with a couple counters blinking a couple LEDs, and the first run took ages. Incredible.Even the GUI, I find slow as f*ck. Opening dialogs for the first time when you launched Vivado takes a couple seconds!Everything seems very slow... I can't say this is a good first experience with Vivado so far... Guess I'll have to live with it to target the 7-series parts...

author: asmi
author_rank: Super Contributor
timestamp: August 28, 2019, 04:45:01 pm
content: Quote from: SiliconWizard on August 28, 2019, 03:17:31 pmCan you define "took ages" in engineering terms? My LPDDR1 controller (which is non-IPI design) takes about 30 seconds for synthesis and about a minute for implementation (and that is due to very tight IO constraints, as static capture/output of 200 MHz DDR is hard for S7 devices in FBGA-196 package because of package delays). The only time it actually bothered me was when I was closing IO timing, as you pretty much have to run implementation very often. But I don't design PHY blocks very often, and once they are done, everything inside the chip is much easier to deal with, and with experience generally you can kinda feel when timing might become an issue without tools just by looking at the code (long strings of combinatorial logic, connections to/from hard IP blocks, insufficient pipelining for the frequency you're trying to achieve).Quote from: SiliconWizard on August 28, 2019, 03:17:31 pmThat's Java for youA price we pay for having cross-platform software.You won't interact with it too often though. I spend like 90+% of my time either staring at the graphs in the simulator (the GUI for waveforms is adequate once the sim run is completed), or writing/reading HDL code (I use external editor).

author: Bassman59
author_rank: Super Contributor
timestamp: August 29, 2019, 08:15:55 pm
content: Quote from: tggzzz on August 28, 2019, 06:54:32 amFor what it's worth, I agree with everything you've said about Xilinx' hostility towards the use of source-code control software for projects using their tools.They FINALLY got their shit together towards the end of ISE 14, when they got religion and made the project file (.xise) text-based XML instead of an opaque binary format that was "touched" the instant the project was opened in the tools. All that the engineer needed to keep in the repository were the sources, the XISE file and the constraint files. There was no need to run magic scripts to rebuild the project or any of that.Then along came Vivado and they fucked it right up again. Incomprehensible project files, directory structures that had to be exactly that set-up otherwise the tools wouldn't work, and no clear and concise rules about what of that had to be in the repo and what was created on the fly as needed. Now I'll be honest and say I haven't looked at Vivado in a couple of years, as I've been using a different vendor's devices (and with them, the main thing I learned was "don't use their project manager tool at all, and instead run Synplify standalone and run the fitter standalone"). But I don't think the source-code-control issue has gotten any better.

author: legacy
author_rank: Super Contributor
timestamp: August 30, 2019, 12:27:16 pm
content: Quote from: richardman on August 17, 2019, 04:27:51 amHP ItaniumI: deadHP ItaniumII: deadAnalog Devices Blackfin: still aliveother examples?

author: legacy
author_rank: Super Contributor
timestamp: August 30, 2019, 12:44:22 pm
content: Quote from: laugensalm on August 27, 2019, 07:56:55 amThat's what I have always been focused on my Arise-v2 core as the debugger engine was born along with the development of the CPU, not later, but in parallel, and a lot of choices about the CPU-design come from the debugger-design.Anyway: I do reccomend Modelsim as simulator.

author: legacy
author_rank: Super Contributor
timestamp: August 30, 2019, 01:07:48 pm
content: Quote from: tggzzz on August 25, 2019, 09:27:12 amWhy do you say that about VLIW?

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2019, 01:13:51 pm
content: Quote from: legacy on August 30, 2019, 01:07:48 pmI didn't say that, so that's a strawman point.Which processor do you know makeshardrealtime guarantees in the sense I mentioned? Enquiring minds want to know.BTW, to be of use, such guarantees should be smiultaneously valid for multiple independent mutually asynchronous inputs/outputs, since that's the nature of real embedded systems.

author: legacy
author_rank: Super Contributor
timestamp: August 30, 2019, 01:36:46 pm
content: Quote from: tggzzz on August 30, 2019, 01:13:51 pmA RISC CPU without pipeline, and without cache. Cycles are all equals.

author: coppice
author_rank: Super Contributor
timestamp: August 30, 2019, 01:50:47 pm
content: Quote from: tggzzz on August 25, 2019, 09:27:12 amIt used to be fairly common for DSP designs to lock the processor clock to the system clock, get the software to initially sync up to the incoming data, and then use cycle accurate code to keep grabbing input and pushing output without any further checks. Caches completely killed this in later DSP oriented processors, and now only the very simplest MCU cores can manage it. Even some small MCUs without caches tend to have pipeline tricks going on that make cycle accurate code impractical.

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2019, 01:57:01 pm
content: Quote from: legacy on August 30, 2019, 01:36:46 pmNow add in the other condition I mentioned that is critical to embedded systems: "BTW, to be of use, such guarantees should be smiultaneously valid for multiple independent mutually asynchronous inputs/outputs, since that's the nature of real embedded systems."Anyotherprocessors achieve that? To have two alternatives would be valuable.

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2019, 02:10:18 pm
content: Quote from: coppice on August 30, 2019, 01:50:47 pmThe caches areoneof the killers.The requirement to have more than a single input stream is another - interrupts kill latency guarantees.But getting a software environment that can cope with such requirements is even more difficult.Now youcanbuy a 4000MIPS (expandable) processor for ~£25 at Digi-key that has such hard realtime performance; the sorfware and IDE specifies the latency between key points in the code by examining the optimised executable.I've used one to simultaneously count (in software) transitions in multiple 62.5Mb/s input streams (i.e. at least a 15MHz input signal), handle front panel i/o, and handle USB comms with a PC. It all came togetherdelightfullyeasily.I'd like to have other processors achieve that. I also think that with the problems with modern semiconductor processes, new design concepts will have to emerge - and this isn't a bad way to get people to consider them.So, while I feel VLIW is a bit of a backward-looking dead-end, there are other challenges that represent the future. Perhaps the OP would like to think about those.

author: coppice
author_rank: Super Contributor
timestamp: August 30, 2019, 02:17:23 pm
content: Quote from: tggzzz on August 30, 2019, 02:10:18 pmA 4GIPS processor or a 4GIPS chip?

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 30, 2019, 02:32:10 pm
content: Quote from: legacy on August 30, 2019, 01:36:46 pmI'm not sure what was exactly meant by hard realtime guarantees, but you don't necessarily need to have fixed execution time to meet them. All you need is a bounded execution time/latency. Now obviously the upper bound must meet your requirements... and in a typical cached system, the upper bound may be unacceptably high. Same for a pipeline, but not as bad if the pipeline length is limited.Now you could still use both and get reasonable hard realtime performance with a proper design. A short pipeline, and as for the cache, write code that can be executed fully in the cache (data included) the whole time you need to get predictable execution time. That would require careful coding, and a compiler that enforces that. It could just preload the cache portion it needs for code and data, execute the "time-critical" section exclusively from/in cache, and then move on to the next section when done. On a multiple-core processor, it would of course require a separate cache for each core.Not all trivial, but that gives some things to think about.

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2019, 02:51:00 pm
content: Quote from: SiliconWizard on August 30, 2019, 02:32:10 pmThat would be fine,if and only if there is a guaranteed upper bound. If you know of a system that provides such a guarantee, I'mveryinterested in hearing about it.But if you think about it for a second, actually that wouldn't help. Since hard realtime operationmustbe based on the worst case timings. Thushaving a cache offers zero benefit. It would be better to delete the cache and either save power or use the silicon in other ways.QuoteOnly if you can believe you can be a little bit pregnant!Hard realtime is all-or-nothing. "Reasonable hard realtime performance" is actually soft realtime performance. In many cases that is perfectly acceptable; I've designed and implemented such systems myself.But nobody should underestimate the unbridgeable gulf between hard and soft realtime systems.QuoteThe i860/80860 had such a cache. There's a reason that experiment hasn't been repeated!The point is that thereisa processor/software family that manages hard realtime multicore processing, and I found ittrivially easy to create a bare-silicon system. I was expecting to encounter problems, but getting an atMega328 or ARM up and running wasmuchmore difficult!I would like to see more such systems; I think they will be commercially and technically important in the future. starting from scratch with no experience of the devkit or the software or the IDE, I was verifying i/o+processing performance within 4 hours! A trivial test to be sure, but getting to that stage usually takes days on other bare-silicon processors.

author: brucehoult
author_rank: Super Contributor
timestamp: August 30, 2019, 03:12:09 pm
content: Quote from: legacy on August 30, 2019, 01:36:46 pmAnd without branch prediction.Our E20 is like that. Two stage pipeline, no cache only SRAM, no branch prediction. Every RV32I instruction takes exactly one cycle cycle every time, except taken branches always take two. You can definitely cycle-count it.

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2019, 03:33:27 pm
content: Quote from: brucehoult on August 30, 2019, 03:12:09 pmAh yes,anotherform or cacheDitto the various address translation buffers in bigger processors.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 30, 2019, 03:34:13 pm
content: Quote from: tggzzz on August 30, 2019, 02:51:00 pmWell, pretty much every system has one. Otherwise that would mean that the upper bound could get infinitely long in some cases. If you know of a system in which it can get infinitely long, I'm interested in hearing about it.As I said, the upper bound in a typical system may just be unacceptably high if you're cumulating all worst cases. But it's never going to be infinite, or else this is a case of deadlock. In some specifically designed systems, the upper bound may allow you to meet your hard deadlines.Sure if you don't have control over the whole hardware your system is going to run on, getting figures will be very difficult.Quote from: tggzzz on August 30, 2019, 02:51:00 pmYes, worst case timings of course.And no, having a cache doesn't offer zero benefit. Of course it doesn't for THIS particular requirement (except that it allows faster execution than running from slower memory!), but has many benefits outside of this, which are all benefits of having a cache: access to large amounts of memory for a reasonable cost, area and power consumption, while keeping a fast access.Quote from: tggzzz on August 30, 2019, 02:51:00 pmNope, I did mean meet the deadlines every single time. The "reasonable" adjective was probably misleading. It wasn't meaning "not always" or "on average". It was meaning "as long as your deadlines are far enough that you will meet them even in the worst case scenario". Again as long as your processor is not too complex (thus having a short pipeline, a simple cache system), the upper bound is not that hard to estimate. Of course this worst case upper bound is what matters for hard realtime, and it will often be pretty high.Quote from: tggzzz on August 30, 2019, 02:51:00 pmI didn't know about the i860, will have to take a look. There's a reason, but you didn't state which? Too complex to properly use? What was exactly implemented?Sure it would make coding for such a processor (and designing the compilers) certainly not trivial, but with the appropriate programming language(s) and compiler(s), that sounds workable. You'd need again to think in "time-critical section" terms. It would also require a CPU with enough cores to make that useful for even moderately complex software.As a side thought, as long as such a processor is fast enough for a given task, you could even get cycle-accurate execution of such task (which of course would have to last for enough clock cycles so that would work). Just make sure the execution of code of the task itself is shorter than the fixed time you allocated to it. Now dedicated internal timers could be used in a single instruction to make the core "sleep" for the remaining amount of time. Sure this would not be the most efficient approach. But it could be interesting in a general-purpose CPU. That approach would of course never be workable if you're targetting cycle-accurate execution of very short tasks.I don't know if you're referring to the XMOS products as an example of success? If so, those are pretty nice indeed. But they still have limited memory as far as I've gotten it, so that wouldn't quite replace a processor which would need to deal with huge amounts of memory. I guess you can work around that by transferring chunks of memory from an external memory when needed, but then, that would yield pretty much the same concept as what I was describing above. You'd just use the XMOS processor internal memory as a cache.

author: brucehoult
author_rank: Super Contributor
timestamp: August 30, 2019, 03:51:47 pm
content: Quote from: tggzzz on August 30, 2019, 02:10:18 pmOnly if the interrupts occur with totally unknown and unbounded frequency. It's easy enough to make interrupt handling fast, and if you know an upper bound for their frequency you can guarantee real-time response for both the interrupts and the background task.QuoteI'm going to take a wild stab in the dark and guess you're talking about XMOS XCore. They are kinda cute with the barrel-processor design, but they do depend on each of the up to 32 (?) threads having a relatively even and equal workload, which poses another kind of software challenge.

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2019, 04:13:30 pm
content: Quote from: SiliconWizard on August 30, 2019, 03:34:13 pmIndeed, but for hard realtime you need the numerical magnitude! Too many people nowadays think adjectives are a substitute for numbersQuoteTrue; that's why I'm explicit about considering hard realtime use cases.QuoteI disagree; I don't think it is tractable.Sure, youcangrossly oversize a system, build, instrument, stimulate, measure - and then hope you caught the worst case value. Boring, and good luck defending that in courtQuoteAnd then it is blown out of the water by an interrupt from something or other!QuoteI am indeed thinking of the xCORE+xC system plus its IDE. I didn't mention it explicitly since I'd like people (the OP?) to start considering alternatives.As for large amounts of memory, memory size was interesting 30 years ago. There are many manymanyembedded processors with "effectively infinite" memory; that's a solved problem. The xCORE devices have more than enough memory to be "interesting" and "usable". Naturally they aren't a panacea, and there will always be limits to their capabilities; at that point FPGAs may be more relevant.But very few ecosystems with usable system timing guarantees. And there are zero others where thesoftwareis designed for multicore operation from the ground up. As usual, it is relatively easy to plonk down lots of parallel hardware, but finding the software that can use it has caused companies to spend vast amounts of money to little effect.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 30, 2019, 04:27:11 pm
content: Quote from: tggzzz on August 30, 2019, 04:13:30 pmNot sure you got the essence of the architecture I was trying to describe.Of course, to make things easily tractable, every time-critical task would have to run strictly on a separate core (within its own cache). So an ISR would have to run on its own dedicated core, and could not interrupt another one. Or at least an ISR would have to run strictly on a core that only runs either nothing else OR a non-time-critical task. The portion of cache allocated to a time-critical task would have to be "locked", meaning it could not be reused for further cache misses if the core it runs on also runs another task that is not time-critical and could potentially trigger cache misses. So a single core could only execute either only one time-critical task, or interruptable non-time-critical tasks (and the ISRs would have low and guaranteed latency and could not be themselves interrupted, so you could only have one per core).Exchanging data between tasks could get hairy. Never said it would be easy.Granted the idea of off-loading hard realtime stuff to smaller and dedicated "processors" is still a simpler approach in many cases, but I was toying with the idea of implementing that on some kind of general-purpose CPU. Could be interesting to investigate if I had a little more spare time.

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2019, 04:34:57 pm
content: Quote from: brucehoult on August 30, 2019, 03:51:47 pmThere's validity to that, of course, but the design and analysis is far from trivial - and I haven't seen it integrated into the language+IDE environment.QuoteI am, and haven't mentioned them explicitly since I'd like people to invent alternatives.Personally I regard the "hyperthreading on steroids" barrel processor as being an uninteresting implementation detail. What's far more interesting is the way that i/o ports are treated exactly as if they are other cores, the inter-core/port comms fabric, andespecially the software conceptsthat ties all that together. That's unique in the hard realtime arena.The xCORE+xC devices aren't general purpose computers, they are embedded devices (doh!). That avoids the necessity and desirability of each core having an "equal" workload, since all you need is for a core to be there when you need it. The normal design pattern is to dedicate a core to a peripheral (I'm using that term very loosely) or computation, where the process is a classicCode:setupforever {wait for something to dodo itsend results}and so long as the latency from the "wait" returning to being invoked again is OK, nobody cares how long the core spends waiting. well, some regular high level languages (Rust, Go) areagainpicking up on some of the key concepts from Hoare's seminal Communicating Sequential Processes concepts.

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2019, 04:50:33 pm
content: Quote from: SiliconWizard on August 30, 2019, 04:27:11 pmindeed!QuoteGood start, provided your caches are ignored. Caches are a mere performance enhancement that might be used when all the other more important system properties have been satisfied. "Get it right, then get it fast"If you have enough cores, you don't need interrupts - just suspend the core until there is something for it to do.QuoteIf you have the right language concepts and abstractions, then exchanging data isunderstandableandusable- to the point of beingeasy.xChasthe right abstractions, being based on Hoare's CSP from the 1970, as implemented in Occam, and now (partially) in Go and Rust. (Unlike the usual mess you see in languages where multicore processing is a distant afterthought).When I kicked the tyres of xC+xCORE, I found remarkably few pain points - and all of them could beeasilyunderstood in terms of what isnecessaryin a multicore world. There waszero"WTF is that feature/limitation there for?"QuoteYou need lots of cores, and the software to enable them to be used.The latter is the traditional black pit, a problem that will become worse over time. Hence my desire to have more people thinking about other solutions.

author: legacy
author_rank: Super Contributor
timestamp: August 30, 2019, 04:52:00 pm
content: Quote from: brucehoult on August 30, 2019, 03:12:09 pmWhen an aircraft flies faster than about 760 mph, the fly-board needs to compliant to level-A, which means hard-realtime.The military departments have many supersonic aircraft, while commercial departments have none because several regulations (in Europe and the US) have banned all commercial aircraft from flying faster than the speed of sound over land.This means constraints have been relaxed to level C-and level-B. Soft-realtime.However, commercial supersonic aircraft (1) could return to the skies, so we have already spent millions of euro with some chip makers, just to be sure to still have our special version of PowerPC which looks like your E20.Funny, ain't it?(1) e.g. the Concorde, flew from 1976 to 2003

author: asmi
author_rank: Super Contributor
timestamp: August 30, 2019, 07:02:59 pm
content: Speaking of PowerPC:IBM Gives Away PowerPC; Goes Open Source

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 30, 2019, 08:08:48 pm
content: Quote from: tggzzz on August 30, 2019, 04:50:33 pmPer-core cache (or per-core dedicated memory if you prefer) would not be just for performance enhancement. It would 1/ allow complete isolation from other cores, and 2/ not having to share a common memory pool would make it hugely easier to meet hard deadlines. "Locked" cache as I hinted previously would be nothing more than per-core dedicated memory. The fact it would also act as cache would just make it easier/faster to get code and get/put data from/to global shared memory.Some of those ideas are probably relatively close to what XMOS has done in fact. I'm merely trying to think about this in some kind of larger and more general-purpose system.Quote from: tggzzz on August 30, 2019, 04:50:33 pmI knew you were all biased by the way XMOS does it.And yes that's right. But still, that's wasteful. If you can share a core as I suggested above, there's a lot more that can be done with a given number of cores.One added benefit of having some kind of interrupt controller is the ability to detect an interrupt trigger while the corresponding "ISR" is already servicing a previous trigger. What you would do with this information would depend on the application of course, but the ability to detect it is interesting. If you just have a task waiting for some condition - well, if the condition appears while the task is busy, you basically miss it. Sure you could always dedicate yet another core just to detect that. Damn, that's a lot of cores doing not much.Quote from: tggzzz on August 30, 2019, 04:50:33 pmYes, but I was not really talking about the abstractions and how the developer would manage that. More about how the hardware would handle data sharing while still guaranteeing hard realtime execution. That's where it gets hairy.All that said, in many systems you can indeed dedicate a small processor to hard realtime tasks instead of trying to cram it all in a general-purpose processor with great difficulties. Not all tasks in a typical realtime system are time-critical.A possible hybrid approach could be to design a processor with a number of "classic" cores for general-purpose computing, and a significantly larger number of simplified cores dedicated to time-critical tasks (possibly with no pipeline, a simplified instruction set, dedicated memory, etc) while being able to all share a common memory pool.

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2019, 09:29:29 pm
content: Quote from: SiliconWizard on August 30, 2019, 08:08:48 pmWith proper programming abstractions, that can be enforced perfectly well in software.Starting with C and/or any unconstrained parallelism operations is most definitely not a proper abstraction in this regard!QuoteThat becomes intractable very quickly, dragon territory in fact!Even if the hard realtime constraint is abandoned, heavy abstractions and constraints are required. A perennial favourite is to aim for "software transactional memory", and even that tends to end up with some very hairy corner cases.QuotexC does have a facility that allows the compiler to automatically combine several processes and execute them on a single core. There are limitations, but they are easily understood and are verified by the compiler before execution.QuoteI always feel having more than two priorities (normal and interrupt) is unclean, and working out the worse case timing and priority inversion (etc) consequences is brittle. Just say no (except in crap systems where you have no alternative).QuoteIn both embedded and large (e.g. high performance computing) areas, shared memory is deprecated in favour of message passing. Basically shared anything is big source of problems.For embedded systems the messages can be passed by hardware FIFOs. In HPC etc systems traditional software FIFOs are used; the difficult concurrency problems are very well contained and simple and testable, and are ignorable in the application code.QuoteIndeed. But in this conversation it is acceptable to push for purity - especially if the alternative is VLIW!QuoteIt can be done, and there are limited big.little processors around. Several systems have failed at the software level, e.g. the Sony/Toshiba/IBM cell processor.As always, programming them is the problem ; the hardware can be built. Hardware/software architecture codesign is essential.

author: tggzzz
author_rank: Super Contributor
timestamp: August 30, 2019, 09:35:38 pm
content: Quote from: SiliconWizard on August 30, 2019, 08:08:48 pmThe XMOS ecosystem is unique (unfortunately) and works well within its domain.I want alternatives to the XMOS ecosystem, with different benefits and niches.

author: brucehoult
author_rank: Super Contributor
timestamp: August 30, 2019, 11:21:32 pm
content: Quote from: tggzzz on August 30, 2019, 09:29:29 pmWe're seeing a lot of demand for this kind of setup.Our demo FU540 chip (on the HiFive Unleashed board) has four U54 application processors with all the big caches and MMUs etc, and one E51 which is RV64IMAC (doesn't have FPU), has a small 16 KB L1 icache (which can be split to as much as 8 KB of locked-down ITIM, and 8 KB of icache), 8 KB DTIM, and just machine mode and user mode. The E51 has a branch predictor but it can be turned off.That's a chip that taped out almost two years ago. A current version would be using U74 (Cortex 55 class dual issue in order) as the application processor(s), and the real-time processors would be probably S21s (very like a Cortex M3, except 64 bit with the full RV64IMAC instruction set). I think the standard configurations (that you can click on a web page and the designs are pre-verified) at present go out to one applications processor and eight minions, but is certainly possible to have more.

author: tggzzz
author_rank: Super Contributor
timestamp: August 31, 2019, 07:30:53 am
content: Quote from: brucehoult on August 30, 2019, 11:21:32 pmWhat is the programming model and/or abstractions (especially with inter-processor comms)? My ignorant guess would be "a few CPUs glued together somehow"I want better than that

author: brucehoult
author_rank: Super Contributor
timestamp: August 31, 2019, 08:02:36 am
content: Quote from: tggzzz on August 31, 2019, 07:30:53 amWhat would you like to see?

author: tggzzz
author_rank: Super Contributor
timestamp: August 31, 2019, 08:46:05 am
content: Quote from: brucehoult on August 31, 2019, 08:02:36 amAplausiblefuture, of courseI don't want to constrain concepts and techniques, other than that they be effective, easy to understand and apply. That does rule out unconstrained C.Currently the best I've seen is CSP and its derivatives, but I hope better can be found.

author: brucehoult
author_rank: Super Contributor
timestamp: September 01, 2019, 03:50:56 am
content: Quote from: tggzzz on August 31, 2019, 08:46:05 amYeah, I read Hoare78 in around 1981 or 1982. I started university in 1981, skipped almost all the lectures, and used it basically for 1) access to real computers (PDP11/VAX) and 2) access to the CACM, SIGPLAN etc archives in the library.Sadly Hoare described only a high level programming language syntax, not really anything about how it should be implemented.Something very close to Hoare's ideas appeared in 4.2BSD in 1983 in the form of things such as socketpair() and popen() and select(). I did some programming in that style using VAX/VMS's Mailboxes and some system call that let you wait for one of a set of mailboxes to have a message. I don't know when VMS got that facility, but it was 1983 or 1984 at the latest as that was when I was doing that stuff.But the question is how do you implement this stuff at the hardware level on a multi-processor system to have both low latency and high throughput?The Transputer provided four serial links to neighbors in hardware, which you accessed at fixed memory addresses using dedicated IN and OUT instructions. Processes on the same Transputer core could communicate using the same IN/OUT mechanism but using an arbitrary memory location.You'd think this might work quite well (at least from a latency point of view), but no one seems keen to emulate it. Pretty much everyone now seems to just be using bulk transfer between caches along with inter-processor interrupts to tell the recipient to take a look.

author: laugensalm
author_rank: Regular Contributor
timestamp: September 01, 2019, 01:47:36 pm
content: Quote from: brucehoult on September 01, 2019, 03:50:56 amThere's some folks following the "NoC" hype (Network on a chip) where several soft cores are routing whatever to each other on a big FPGA. Don't have any specific pointers though...I keep picking up randomly.Also used to be the 'MUSIC' supercomputing concept from ETH Zürich (led by Anton Gunzinger, I believe), where I remember some low latency message passing aspects that made the beast competitive at that time, although I also remember some setbacks with the PCB technology back then. Still, old tech can sometime be ahead of its time and worth to be dug up again.Funny that you mention transputers. I still think it's an interesting concept to follow, and in some way, concerning hardware, dead simple. But it's the tools and languanges that can become painful in the engineering process.If you just need a real time guarantee of like X nanoseconds for a response to an event, there are a few DSPs doing the job just fine (Blackfin probably being the best known hybrid for that purpose). For a defined cycle accurate, fully deterministic response that can be verified, it is probably just cheaper and easier to prove in form of a dedicated hardware unit instead of using a general purpose CPU.Especially when it comes to safety aspects, proving that a CPU works right (and has a 'failsafe' fallback scenario, possibly) gets much more complex than running the full coverage for the pure hard logic scenario.So after all, we engineers probably will go for a pure HDL coding session to keep the risks low for a project where requirement specs and budgets are set.The nice thing with the FPGA is still, that you're free to define your own coprocessor for a specific purpose. I am wondering how far this is thought through with the RISC-V. The MIPS-Arch defined some more or less useful coprocessor extensions, I think it can be done better. I've experimented with some old transputer concepts to do inline DSP operations on a somewhat classic stack machine, eventually, the SM is just used for setting up the microcode area to get a good latency. Instead of threads, we duplicate cores.

author: legacy
author_rank: Super Contributor
timestamp: September 01, 2019, 03:21:40 pm
content: Quote from: laugensalm on September 01, 2019, 01:47:36 pmThis cannot be easily accepted in avionics since HDL is not spec as software, but rather as hardware, and specs for hardware are more more complex and fussy than specs for software.

author: legacy
author_rank: Super Contributor
timestamp: September 01, 2019, 03:24:51 pm
content: Quote from: brucehoult on September 01, 2019, 03:50:56 amProbably this way

author: tggzzz
author_rank: Super Contributor
timestamp: September 01, 2019, 04:01:42 pm
content: Quote from: legacy on September 01, 2019, 03:24:51 pmIf it is shared memory, it is only scalable until it hits one of several brick walls.Memory throughput is the obvious one. The AMD processors ran into cache coherency problems. There are others.

author: legacy
author_rank: Super Contributor
timestamp: September 01, 2019, 04:32:54 pm
content: Quote from: tggzzz on September 01, 2019, 04:01:42 pmPrecisely! That book is focused on an old technology developed by MIT before SGI put it into the commercial name of "Numaflex" to remark their supremacy regarding reality engines and graphics pipes, e.g. military flight simulators(1), commercial things with million dollars invested that must have both low latency and high throughput constraints.So, the book addresses something with a solid business on it shoulders, but that book also addresses different topics, with the conclusion that ... you can talk as long as you wish, at the end, no matter how much you effort and money you invest, you will never have both low latency and high throughput.(1) some are still used for the training of helicopter and aircraft pilots

author: brucehoult
author_rank: Super Contributor
timestamp: September 01, 2019, 07:06:46 pm
content: Quote from: laugensalm on September 01, 2019, 01:47:36 pmJan Gray is the obvious one. He showed 1680 RV32I cores on a single FPGA, along with his "Hoplite" NoC, several years ago. When I last talked with him six months or so ago he was working on a custom AMI for Amazon F1 FPGA instances that people could rent. I haven't heard about the progress on that.

author: legacy
author_rank: Super Contributor
timestamp: September 01, 2019, 07:54:18 pm
content: Quote from: brucehoult on September 01, 2019, 07:06:46 pmhow do they talk each to the others? via messag passing on a simulated network? if so, with which working model?

author: tggzzz
author_rank: Super Contributor
timestamp: September 01, 2019, 08:15:43 pm
content: Quote from: brucehoult on September 01, 2019, 03:50:56 amBoth more and less than that!His was a mathematical formalism of things that can be implemented in software, hardware, paper and pencil, abacuses etc. The real strength of that is that is possible to do some deductive reasoning - unlike almost all other implementation techniques.The concepts were directly migrated into one computer language: Occam, which had noticable limitations.The modern (commercially successful) incarnation of Occam is xC. It is effectively Occam with a C syntax, and with the unnecessarily dangerous bits of C prohibited by the compiler (e.g. aliasing).QuoteEr, those concepts are a subset of the concepts in CSP. Have a look at Go and Rust, and you will see other concepts from CSP.QuoteThe techniques you mention are those thatcan be retrofittedonto bog-standard general purpose computers. If you start from scratch and throw out preconceptions of what's in a computer, you can end with systems with significantly different properties and significant advantages.Look at the xCORE devices running xC processes. They work well in the hard realtime embedded arena, but they are not intended to be general purpose computers.We need more such thinking, especially if we are to continue to progress now that semiconductor scaling has run up against some pretty fundamental limits. If the OP is prepared to look at VLIW, maybe he could look at other "strange and novel" concepts

author: brucehoult
author_rank: Super Contributor
timestamp: September 01, 2019, 10:25:17 pm
content: Quote from: legacy on September 01, 2019, 07:54:18 pmhttps://carrv.github.io/2017/slides/gray-phalanx-carrv2017-slides.pdfhttps://carrv.github.io/2017/papers/gray-phalanx-carrv2017.pdf

author: laugensalm
author_rank: Regular Contributor
timestamp: September 02, 2019, 10:17:40 am
content: Quote from: legacy on September 01, 2019, 03:21:40 pmSo you're basically saying, that once you got your HDL/HW certified after DO-something rules, you'd never touch it again and try making everything in software?I know nothing about this so far, I just observed with some SIL-3 related discussions that effective safety and failsafe operation can be very questionnable, when you've got a CPU where the garbage in/garbage out principle applies when you've got too much logic with potentially flipping bits (radiation, ...).This is probably where the good old inmos stack machine concept is easier to verify with the full scenario coverage included. It seems that stack machines are still en vogue with current space technologies.While at it: there's some other nerdy concept from CPU veteran Chuck Moore which has made it into silicon:http://www.greenarraychips.com/(I have no idea however how they communicate). There are a few communities quite active in Forth CPU development, one of the simplest cores ever is probably the J1 CPU.I wonder how good old Occam would map into Forth? It's certainly a painful path from C to effective Stack machine assembly (speaking of GCC register transfer language concepts in particular), so maybe eventually, we'd have to drop this legacy for "new tech".

author: legacy
author_rank: Super Contributor
timestamp: September 02, 2019, 02:57:57 pm
content: Quote from: laugensalm on September 02, 2019, 10:17:40 amPrecisely.

author: tggzzz
author_rank: Super Contributor
timestamp: September 02, 2019, 03:31:10 pm
content: Quote from: brucehoult on September 01, 2019, 10:25:17 pmGetting the right "granularity" (for want of a better word) is key.Hardware on its own is easy - as has been demonstratedmanytimes.There have been very few successful demonstrations of useful software on top of such hardware. The last page of that slideset is honest: one of the points is "Value proposition unproven, awaits workloads".It will be interesting to see the effects of having the SDK, after it becomes available.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 02, 2019, 03:43:08 pm
content: Quote from: legacy on September 02, 2019, 02:57:57 pmThat's interesting. In other industries, software IS the nightmare for certification now, more so than hardware is.

author: legacy
author_rank: Super Contributor
timestamp: September 02, 2019, 03:56:17 pm
content: Quote from: SiliconWizard on September 02, 2019, 03:43:08 pmHigh-speed trains have the same problem. I have recently helped a customer to pass certifications and I was working on a bugged version of the TI/320 DSP. Do they know the bug? Yes, can they change the chip with the BUG-free version? No! So the software needs to patch the problem.Testing the hardware is (formally and informally) *MORE* complex than testing the software, it's *MORE* expensive, and it requires *MORE* time and effort.

author: coppice
author_rank: Super Contributor
timestamp: September 02, 2019, 04:37:58 pm
content: Quote from: legacy on September 02, 2019, 03:56:17 pmThey are both a nightmare to test if you aim to be thorough. In some ways hardware is worse, as it varies from sample to sample, but asynchronous issues in software give hardware a close run. If you are determined to be truly thorough you just get depressed and give up. The world only moves forwards because people have a somewhat relaxed attitudes to testing.

author: coppice
author_rank: Super Contributor
timestamp: September 02, 2019, 04:45:23 pm
content: Quote from: tggzzz on September 02, 2019, 03:31:10 pmAny particular granularity can only ever be suitable for a small range of problems. The question is whether its good enough for some problems with huge volumes, that can finance the development. Otherwise it will fade away.Quote from: tggzzz on September 02, 2019, 03:31:10 pmHardware on its own tends to look good. Then you add software to try to use it, and you realise it only does a few things well.Quote from: tggzzz on September 02, 2019, 03:31:10 pmWorkloads are such a downer. They've ruined so many promising designs.Quote from: tggzzz on September 02, 2019, 03:31:10 pmYeah, that's usually where the disappointment kicks in. From the talk this looks a lot like back to the 80s thinking, so I'm not hopeful.

author: brucehoult
author_rank: Super Contributor
timestamp: September 02, 2019, 07:10:33 pm
content: Quote from: tggzzz on September 01, 2019, 08:15:43 pmYes, I completely agree that a formalism you can reason about and create proofs is a very valuable thing.QuoteA subset, yes, but a useful one and I think clearly influenced by CSP, just several years later. Go and Rust are 30 or 35 years later.QuoteYou also end up with systems that don't run the billions of lines of existing code out there, or don't run it well. That's ok for sufficiently specialized uses.QuoteWe live in an amazing world now where it could be a genius kid in her bedroom in Fiji who comes up with the winning idea and proves it out with soft cores in a $100 (or even $10) FPGA.

author: tggzzz
author_rank: Super Contributor
timestamp: September 02, 2019, 07:21:06 pm
content: Quote from: brucehoult on September 02, 2019, 07:10:33 pm"Crossing the Chasm", and all that!It may turn out that, while existing systems will continue to be used, over the generations some different paradigms (ugh!) will be used for new applications. We are already beginning to see such things, with "strange new" algorithms becoming important, e.g. map-reduce and the various "AI" neural nets.I see no fundamental reason why that won't apply to other aspects of architectures. In fact some of the neural net concepts are finding their way into mainstream processors, in a tentative and unproven way.

author: tolpe
author_rank: Newbie
timestamp: September 05, 2019, 06:39:46 am
content: Quote from: legacy on September 02, 2019, 03:56:17 pmDepends on how you look at it, and if you consider reprogrammable logic as true hardware.I wouldn't unconditionally second that opinion. Focusing on a CPU, it is actually quite easy to prove full coverage for a specific architecture designed for less complexity, especially when it comes to failsafe aspects. Software introduces way more complexity and possible paths where things can go wrong. So you'd in many cases better off with implementing a simple hard logic instead of a software routine (e.g. for a PID controller).Typically you'd put the entire system into a model in the loop and throw error scenarios at it - it is always more complex when involving software in the sense of a classic programming sequence. But ok, there are different safety standards, discussing these would be a bit off topic now.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 05, 2019, 04:43:34 pm
content: Quote from: legacy on September 02, 2019, 03:56:17 pmThat's definitely not something that can be generalized and claimed without context.

author: legacy
author_rank: Super Contributor
timestamp: September 06, 2019, 08:33:01 pm
content: Hardware is a physical electro-mechanical device, it can only partially be represented by a behavioral HDL model. Bugs in hardware devices will mostly be random or only found in one particular device, or in particular physical conditions, whereas software bugs are more systematic, hence easier to recreate. So if a bug is found in one of our drafts (firmware that hasn't yet passed the test-report), the same bug will usually be repeatable in the developer’s environment too, which is not the case with hardware when the problem is not representable by an HDL behavioral.We have HDL drafts that do pass the test report on ModelSim, and do not pass it when synthetized.Besides, HDL design about soft cores is too prone to be forked in different interpretations regarding certain features, which means that the final behavior will be different from an ASIC CPU, and yet again, this consumes more time to sort it out, because you have to compare the two (cycle-accurate? oh, more work here)Hardware testing needs to be thorough and precise because if a bug is missed, the cost of fixing it later is huge, whereas in software it is not as costly.You cannot investigate a hardware bug and reprogram an FPGA without blocking all the squads who are working on the prototype, and since we do not have many prototypes (because they are very expensive), this means you have to pay guys (firmware developers, and testers) even if they are idle.Testing software requires many-many test cases to be written, whereas testing the hardware behavioral doesn’t need so much, and you only have to verify whether it functions as intended in normal circumstances and conforms to the design schema and constraints. This is what we usually do with a TestBench on Modelsim, but this is not enough, and we also have to verify the physical FPGA's behavior with an LA (a lot of LA probes, here and there), programming stimulus in a PC software, so at the end we need to test it against different conditions (normal conditions, and abnormal conditions, regarding voltages, humidity, temperature, noises, etc) and data inputs, so the scenarios will be more similar to software testing, hence the number of test cases.