JOP as SOPC component
in [FPGA]
|
Prev: Embedded clocks
Next: CPU design
From: KJ on 30 Aug 2006 07:31 "Martin Schoeberl" <mschoebe(a)mail.tuwien.ac.at> wrote in message news:44f4e0c4$0$11352$3b214f66(a)tunews.univie.ac.at... >> proprietary Altera design, or are there open source implementations >> available?" The switch fabric itself can easily be written, it is on the >> order of six lines of code per interface for a point to point connection, >> there is nothing really magic in what Altera spits out of SOPC Builder >> based > > I think that this is actually the power of SOPC builder. It will > do all your glue logic stuff for the interconnect (address > decoding, byte order managing, byte enable on write,...). > > And that's a lot more than 6 lines of code ;-) You missed my caveats about the 6 lines of code being 'per interface' for a 'point to point connection'. Below is the six lines of code that will implement what SOPC Builder spits out for such an interface when neither master or slave has latency. 1: slave_chipselect <= (master_read or master_write) and To_Std_Logic(master_address = Hard_coded_Address_range); 2: slave_write <= master_write; 3: slave_read <= master_read; 4: slave_writedata <= master_writedata; 5: master_waitrequest <= slave_chipselect and slave_waitrequest; 6: master_readdata <= slave_readdata; When you have a latency aware master and a slave then there is the one additional line of code to connect the two 'readdatavalid' signals. Obviously these are the most simple cases, but surprisingly enough I've found that between functional blocks on a single chip the six lines (or seven) are in many cases sufficient. When you get into the various forms that a master and slave can take the number of lines of code per interface can balloon quite rapidly since you need to take into account differences in data bus widths, connecting latency aware master/slaves to ones that are not, multiple bus masters, etc. I completely agree with you though about the power of SOPC Builder as a tool to implement that somewhat rote exercise of interconnect based on information solely in the .PTF file. I did run into several problems in using SOPC Builder that generated several service requests to Altera that resulted in - Me having to completely replace the SOPC Builder generated code. But since I was connecting all Avalon components it was a tedious (but totally straightforward) process. - Getting a T-shirt from Altera for pointing out the various deficiencies in their tool....and I thought the tool, having been around for several years, would've been a bit sturdier. - Promises from Altera to improve the tool. Supposedly it is much better in Quartus 6, I haven't tried yet but I will because even if I end up having to go down the same path, what SOPC Builder brings to the table has the potential to replace a good chunk of tedious, mindless work. > >> an open source version of this connection logic, but whether simple use >> of the Avalon bus without also targetting an Altera device (even if no >> Altera software is involved) is violating anything is an open legal >> question as you've pointed out (I'm guessing that it might but not really >> sure). > > AFAIK the bus definition is kind of open-source - free. That's my belief but I haven't really investigated whether that is true or not. > However, > I'm sure you're not allowed to use the SOPC builder generated > VHDL code on a Xilinx device ;-) That is definitely the case. > BTW: I asked Altera Austria about a related topic: Is it allowed > to 'use' the DRAM controller in an open-source environment (means > can I upload the VHDL code to a web server). However, they had > no real answare to this. They sayed that the SDRAM controller > does is part of NIOS and does only work with NIOS. Therefore, > one has to buy a NIOS license. But it works quite well with JOP > too ;-) I'm not sure that's really true. I think the SDRAM and DDR controllers are bundled as a part of Altera's Megacore which is a part of Quartus. You can use all of those and SOPC Builder without a NIOS license. I'm also thinking though that the DRAM controller itself would not be open source since it was generated by Altera for use by people that they would like to target Altera devices. > >> Section 2 >> In the paragraph starting "The third issue is..." you ask the question >> "Why not force the slaves to hold the data on the output registers as >> long as there is no new transaction?" A couple follow up questions to >> that though would be >> - What is a SimpCon slave to do if there IS a new transaction before the >> old one has been acknowledged? > > good question ;-) It depends on the pipeline level. It can accept > it. But this is not directly related on the request to 'just' > keep the data valid until a newer one is available (and was > requested). I was going the devil's advocate route and asking what 'should' happen since if a new read starts before the old one has been acknowledged this implies that the slave would then have to keep a queue of 'previously requested but not yet read acknowledged' data somewhere. Presumably when that queue fills up the slave would have to have someway to say 'Stop! I can't take it anymore' which I *think* might mean that the SimpCon slave would keep rdy_cnt set to 3. > >> - Does the SimpCon fabric prevent this from happening? (I think it does, >> but not exactly sure) > > It is the master who decides when to issue a new request > and when to leave the slave with the last data. And this may also be the answer to the above that a SimpCon master is not allowed to initiate a new request until it has acknowledged reading the previous. >> having the master 'know' the latency about the 'slave' would seem to be >> cheating (since this wasn't required by the SimpCon implementation as I >> had thought) but I guess I'll fall back to what Tommy mentioned earlier >> that since JOP was optomized for SimpCon in the first place it implies >> that an Avalon/SimpCon bridge must be built and such bridges can tend to >> be either > > about cheating and bridge: I'm allready cheating on the Avalon > interface (as mentioned in an earlier post) to generate the > address/control/data holding in the master - I switch between > the original single cycle register at the first cycle > and a hold register on the following cycles - that's not > allowed |