Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I am still trying to figure out this issue of odd/even offset. My suspicion has fallen on a dual clock fifo (32 bit wide) because when at some stage its depth was 8 then odd/even offset was 8 samples. Now its depth is 16 and odd/even offset is 16. The next question is why would a fifo behave like that even if clocks change phase or fifo gets empty/full. The fifo is protected against empty/full preventing read/write. The clocks are asynchronous. It is a straight forward dc fifo with several other like it in the design but only this one shows the problem occasionally. I am planning to use dual port ram instead but wanted to know what has gone wrong. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158126
On 8/13/2015 6:07 AM, Philipp Klaus Krause wrote: > The SDCC PIC backends are not up to the standard of the others. Is the PIC too much of an odd ball to keep up with or is there no future in 8-bit PIC ? or are 32-bit chips more fun ? If there is a better place to discuss this, please let me know.Article: 158127
On 8/13/2015 10:11 AM, hamilton wrote: > On 8/13/2015 6:07 AM, Philipp Klaus Krause wrote: >> The SDCC PIC backends are not up to the standard of the others. > > Is the PIC too much of an odd ball to keep up with > or > is there no future in 8-bit PIC ? > or > are 32-bit chips more fun ? > > If there is a better place to discuss this, please let me know. I don't know tons about the 32 bit chips which are mostly ARMs. But the initialization is more complex. It is a good idea to let the tools handle that for you. All of the 8 bit chips I've used were very simple to get off the ground. -- RickArticle: 158128
On 13.08.2015 16:11, hamilton wrote: > On 8/13/2015 6:07 AM, Philipp Klaus Krause wrote: >> The SDCC PIC backends are not up to the standard of the others. > > Is the PIC too much of an odd ball to keep up with > or > is there no future in 8-bit PIC ? > or > are 32-bit chips more fun ? I don't consider 32-bit chips more fun. I like CISC 8-bitters, but I prefer those that seem better suited for C. Again SDCC has few developers, and at least recently, the most active ones don't seem that interested in the pics. Also, the situation is quite different between the pic14 and pic16 backends. The pic16 backend is not that bad. If someone puts a few weeks of work into it, it could probably make it up to the standard of the other ports in terms of correctness; it already passes large parts of the regular regression test suite. The pic14 would require much more work. > > If there is a better place to discuss this, please let me know. > The sdcc-user and sdcc-devel seem a better place than comp.arch.fpga. PhilippArticle: 158129
On Thursday, August 13, 2015 at 9:00:13 AM UTC-4, kaz wrote: >=20 > The next question is why would a fifo behave like that even if clocks > change phase or fifo gets empty/full.=20 >=20 If your suspicion is correct, then it is because there is a bug in the dual= clock design. I know that sounds trite, but you can't discount the obviou= s. > The fifo is protected against empty/full preventing read/write. The clock= s > are asynchronous. It is a straight forward dc fifo with several other lik= e > it in the design but only this one shows the problem occasionally. >=20 Home grown fifo design? > I am planning to use dual port ram instead but wanted to know what has > gone wrong. >=20 Even if the fifo is not home grown, I would suggest switching to another du= al clock fifo design first for the following reasons: - It's going to be quicker to check this out since in some sense all you ha= ve to change is the entity that is being instantiated and possibly renaming= parameters and ports - You get another tidbit of information. If the design still fails in the = same way, then it 'could' be that the fifo is OK after all. If the design = works, then it 'could' be that you're right about there being a problem in = the fifo. If you go down the 'use dual port ram instead' path instead, this is simply= re-inventing the dual clock fifo. Dual clock fifo designs are already bas= ed on dual port ram anyway. Going down that road is probably not the best = way to go about getting to a solution. If the problem really is in the fifo, then it would be better to mentally t= race it back in order to figure out what you could then instrument. In thi= s particular case what I mean is that from what you describe, it looks like= a bit in the read address is perhaps into the wrong state. So accept that= as a given and work out what are the implications of that condition? One = implication if the address pointer is suddenly wrong might be an unusual ch= ange in the number of entries in the fifo (like increasing after a read, or= decreasing after a write or just changing by a 'large' amount over a short= period). Now add some logic to monitor that condition and bring the resul= ts of that monitor out to a pin that you can trigger on. For example, mayb= e the number of words in the fifo should never change by more than 4 betwee= n any two read side clock cycles. So add some code that will detect that c= ondition. Repeat for other conditions that you can come up with. Kevin JenningsArticle: 158130
The fifo is not home grown. It is altera fifo core. We never discard well tried cores for home made work. DC fifo is built by Altera around dual ram but if (as in my case) the clock rates are predictable then one can control wr/rd pointers each in their clock domain without having to cross clock domains thus reducing risk and resource. That is my point and is well known design recommendation. The fifo in question is just 32 bit wide dc fifo from altera core with internal pipe set to 3, rd/wr protected, connected to clk 368.64 at write side enabled 2/3 and connected to 245.76 on the read side always enabled. Initially the read enable is delayed to wait for few words (even though it is protected). Timing is clean. I imagine the write pointer is working but the read pointer is toggling between 0 and 15 with two clock delays leading to samples 0,17,2,19 ...etc. Just a guess. I have put a ram to capture few data from this fifo in the field when problem occurs and I am awaiting results. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158131
Am Donnerstag, 13. August 2015 21:00:07 UTC+2 schrieb kaz: > The fifo is not home grown. It is altera fifo core. We never discard well > tried cores for home made work. >=20 > DC fifo is built by Altera around dual ram but if (as in my case) the > clock rates are predictable then one can control wr/rd pointers each in > their clock domain without having to cross clock domains thus reducing > risk and resource. That is my point and is well known design > recommendation. >=20 > The fifo in question is just 32 bit wide dc fifo from altera core with > internal pipe set to 3, rd/wr protected, connected to clk 368.64 at write > side enabled 2/3 and connected to 245.76 on the read side always enabled. > Initially the read > enable is delayed to wait for few words (even though it is protected). >=20 > Timing is clean. I imagine the write pointer is working but the read > pointer is toggling between 0 and 15 with two clock delays leading to > samples 0,17,2,19 ...etc. Just a guess. >=20 > I have put a ram to capture few data from this fifo in the field when > problem occurs and I am awaiting results. > --------------------------------------- > Posted through http://www.FPGARelated.com I have seen random/strange issues with Altera FIFOs in the past more than o= nce (but still seldom). In that cases I replaced the FIFOs with "home grown= " ones and the problems were solved. I never tracked that down in detail (m= aybe it was related to the clear signal in some way...) and I also cannot r= emember details (one or two clocks, same or different width in/out), I have= used so many FIFOs (mostly successfully) over the years... I would suggest to look at all inputs and outputs of the FIFO with SignalTa= p and see if it behaves correctly. P.S.: Oh, I just read your initial post that you cannot reproduce it in the= lab... P.P.S.: I have googled around to find an old post of me regarding this. I f= ailed. But I found this: https://www.altera.com/support/support-resources/knowledge-base/solutions/r= d11182011_10.html and this: https://www.altera.com/support/support-resources/knowledge-base/solutions/r= d02232015_507.html (Maybe there are more...) So I would suggest to replace the FIFOs with a home grown approach and look= if this solves the issues in field... Regards, Thomas www.entner-electronics.com - Home of EEBlasterArticle: 158132
Thanks Thomas. These two links could explain it well though my quartus is older version but I assume Altera have bug in reporting their bug as well. The link says the possibility of failure increases with speed and logic size. Our speed of 368.64/245.76MHz is certainly fast and the logic we have is massive. Altera says unpredictable behaviour in hardware without telling as what sort of behaviour. I will certainly go for dual port ram without grey counter or clock crossing. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158133
> Again SDCC has few > developers, and at least recently, the most active ones don't seem that > interested in the pics. >=20 Back to the topic of the open FPGA tool chain, I think there would be many = "PICs", i.e. topics which are addressed by no / too few developers. But the whole discussion is quite theoretical as long as A & X do not open = their bitstream formats. And I do not think that they will do anything that= will support an open source solution, as software is the main entry obstac= le for FPGA startups. If there would be a flexible open-source tool-chain w= ith large developer and user-base that can be ported to new architectures e= asily, this would make it much easier for new competition. (Think gcc...) Also (as mentioned above) I think with the good and free tool chains from t= he suppliers, their would be not much demand for such a open source tool ch= ain. There are other points where I would see more motiviation and even the= re is not happening much: - Good open source Verilog/VHDL editor (Yes, I have heard of Emacs...) as t= he integrated editors are average (Altera) or bad (Xilinx). (Currently I am= evaluating two commercial VHDL editors...) - A kind of graphical editor for VHDL and Verilog as the top/higher levels = of bigger projects are often a pain IMHO (like writing netlists by hand). I= would even start such a project myself if I had the time... But even with such things where I think would be quite some demand, the "cr= itical mass" of the FPGA community is too low to get projects started and e= specially keep them running. ThomasArticle: 158134
On 8/13/15 9:44 PM, thomas.entner99@gmail.com wrote: >> Again SDCC has few >> developers, and at least recently, the most active ones don't seem that >> interested in the pics. >> > Back to the topic of the open FPGA tool chain, I think there would > bemany "PICs", i.e. topics which are addressed by no / too few developers. > > But the whole discussion is quite theoretical as long as A & X do > not open their bitstream formats. And I do not think that they will do > anything that will support an open source solution, as software is the > main entry obstacle for FPGA startups. If there would be a flexible > open-source tool-chain with large developer and user-base that can be > ported to new architectures easily, this would make it much easier for > new competition. (Think gcc...) > > Also (as mentioned above) I think with the good and free tool chains > from the suppliers, their would be not much demand for such a open > source tool chain. There are other points where I would see more > motiviation and even there is not happening much: > - Good open source Verilog/VHDL editor (Yes, I have heard of > Emacs...) > as the integrated editors are average (Altera) or bad (Xilinx). > (Currently I am evaluating two commercial VHDL editors...) > - A kind of graphical editor for VHDL and Verilog as the top/higher levels of bigger projects are often a pain IMHO (like writing netlists by hand). I would even start such a project myself if I had the time... > > But even with such things where I think would be quite some demand, > the "critical mass" of the FPGA community is too low to get projects > started and especially keep them running. > > Thomas > One big factor against an open source tool chain is that while the FPGA vendors describe in general terms the routing inside the devices, the precise details are not given, and I suspect that these details may be considered as part of the "secret sauce" that makes the device work. The devices have gotten so big and complicated, that it is impractical to use fully populated muxes, and how you chose what gets to what is important. Processors can also have little details like this, but for processors it tends to just affect the execution speed, and a compiler that doesn't take them into account can still do a reasonable job. For an FPGA, without ALL the details for this you can't even do the routing.Article: 158135
Hello, Am Donnerstag, 13. August 2015 23:40:39 UTC+2 schrieb kaz: > Altera says unpredictable behaviour in hardware without telling as what > sort of behaviour. I will certainly go for dual port ram without grey > counter or clock crossing.=20 I have no experience with Altera, but remember long time ago a "bug" for Xi= linx with RAM, where I heard this was in fact related to weakness in test r= outines to identify production failures. Microsemi had also ~2 years ago so= me RAM related issues were I believer long routing of signals addressing RA= M was not correct annotated which might lead to STA say clean, but real tim= ing was not clean. =20 I had once a problem with a design, which behaved in rare cases in field st= range while lab showed long time no problem and it took very long to track = the error to an bug in external USB software, I know therefore how nasty it= is to proove over and over again, that fpga internal timing is fine for ev= ery clock crossing. regards ThomasArticle: 158136
On Thursday, August 13, 2015 at 5:40:39 PM UTC-4, kaz wrote: > Thanks Thomas. These two links could explain it well though my quartus is > older version but I assume Altera have bug in reporting their bug as well= . What version of Quartus are you using? The one link says it applies only t= o 11.1 with a fix starting with 11.1 SP1. The other link does not specify = a software version number but the report is dated just over one month ago w= hich suggests that the problem has resurfaced. Your best bet then would be= get on Altera to see what the latest word is on a fix here > The link says the possibility of failure increases with speed and logic > size.=20 I see no mention of that > I will certainly go for dual port ram without grey counter or clock cross= ing.=20 This doesn't make much sense...but anyway, it appears that there is anecdot= al evidence of a problem with applying timing constraints that can cause th= e fifo you are using to fail so you're likely getting to the root cause. Kevin JenningsArticle: 158137
On Thursday, August 13, 2015 at 5:40:39 PM UTC-4, kaz wrote: > Thanks Thomas. These two links could explain it well though my quartus is > older version but I assume Altera have bug in reporting their bug as well. What version of Quartus are you using? The one report is specific to only 11.1 with a fix in 11.1 SP1. The other report is from a bit over a month ago and doesn't link it to a specific version but obviously the problem seems to have resurfaced. > The link says the possibility of failure increases with speed and logic > size. No it doesn't > I will certainly go for dual port ram without grey counter or clock crossing. This makes no sense...but in any case you now have anecdotal evidence of how incorrect timing constraints can result in a failure of the fifo that you are using so you are likely close to a solution. Kevin JenningsArticle: 158138
>On Thursday, August 13, 2015 at 5:40:39 PM UTC-4, kaz wrote: >> Thanks Thomas. These two links could explain it well though my quartus is >> older version but I assume Altera have bug in reporting their bug as >well. > >What version of Quartus are you using? The one report is specific to only >11.1 with a fix in 11.1 SP1. The other report is from a bit over a month >ago and doesn't link it to a specific version but obviously the problem >seems to have resurfaced. > >> The link says the possibility of failure increases with speed and logic >> size. > >No it doesn't > here is the copy/paste from second link The probability of a hardware failures increases as the logic utilization and DCFIFO clock rates increase. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158139
> >> I will certainly go for dual port ram without grey counter or clock >crossing. > >This makes no sense... > >Kevin Jennings Kevin, I will be interested to see why it doesn't make sense. Though wr/rd clocks are asynchronous but write rate = read rate regularly. I don't need to worry about pointer/flag crossing. fifo is 16 words deep. I wait till it is half full and start reading non stop each side running its own address generated in its clock domain. It should have been dual port ram only in the first place. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158140
On Friday, August 14, 2015 at 9:17:56 AM UTC-4, kaz wrote: >=20 > I will be interested to see why it doesn't make sense. "...without grey counter or clock crossing" didn't make much sense since yo= u still have two clocks and there will still be clock domain crossings. Th= ose crossings will just occur between domains where there is a specified ph= ase relationship which does open up alternative solutions over situations w= here you don't have such a relationship. It's not worth belaboring here, s= ounds like you know what you want to implement. KevinArticle: 158141
On 8/13/2015 11:17 PM, Richard Damon wrote: > On 8/13/15 9:44 PM, thomas.entner99@gmail.com wrote: >>> Again SDCC has few >>> developers, and at least recently, the most active ones don't seem that >>> interested in the pics. >>> >> Back to the topic of the open FPGA tool chain, I think there would >> bemany "PICs", i.e. topics which are addressed by no / too few >> developers. >> >> But the whole discussion is quite theoretical as long as A & X do >> not open their bitstream formats. And I do not think that they will do >> anything that will support an open source solution, as software is the >> main entry obstacle for FPGA startups. If there would be a flexible >> open-source tool-chain with large developer and user-base that can be >> ported to new architectures easily, this would make it much easier for >> new competition. (Think gcc...) >> >> Also (as mentioned above) I think with the good and free tool chains >> from the suppliers, their would be not much demand for such a open >> source tool chain. There are other points where I would see more >> motiviation and even there is not happening much: >> - Good open source Verilog/VHDL editor (Yes, I have heard of >> Emacs...) >> as the integrated editors are average (Altera) or bad (Xilinx). >> (Currently I am evaluating two commercial VHDL editors...) >> - A kind of graphical editor for VHDL and Verilog as the top/higher > levels of bigger projects are often a pain IMHO (like writing netlists > by hand). I would even start such a project myself if I had the time... >> >> But even with such things where I think would be quite some demand, >> the "critical mass" of the FPGA community is too low to get projects >> started and especially keep them running. >> >> Thomas >> > > One big factor against an open source tool chain is that while the FPGA > vendors describe in general terms the routing inside the devices, the > precise details are not given, and I suspect that these details may be > considered as part of the "secret sauce" that makes the device work. The > devices have gotten so big and complicated, that it is impractical to > use fully populated muxes, and how you chose what gets to what is > important. I'm not sure what details of routing aren't available. There may not be a document which details it all, but last I saw, there were chip level design tools which allow you to see all of the routing and interconnects. The delay info can be extracted from the timing analysis tools. As far as I am aware, there is no "secret sauce". > Processors can also have little details like this, but for processors it > tends to just affect the execution speed, and a compiler that doesn't > take them into account can still do a reasonable job. For an FPGA, > without ALL the details for this you can't even do the routing. Timing data in an FPGA may be difficult to extract, but otherwise I think all the routing info is readily available. -- RickArticle: 158142
On 8/14/2015 9:58 AM, KJ wrote: > On Friday, August 14, 2015 at 9:17:56 AM UTC-4, kaz wrote: >> >> I will be interested to see why it doesn't make sense. > > "...without grey counter or clock crossing" didn't make much sense since you still have two clocks and there will still be clock domain crossings. Those crossings will just occur between domains where there is a specified phase relationship which does open up alternative solutions over situations where you don't have such a relationship. It's not worth belaboring here, sounds like you know what you want to implement. I'm not clear on how a clock domain crossing can have any timing restrictions. Clock domain crossings can be between async clocks which can have any phase relationship on any clock edge, varying with each cycle. So how can you possibly apply timing constraints to that? -- RickArticle: 158143
On 8/14/15 1:29 PM, rickman wrote: > On 8/13/2015 11:17 PM, Richard Damon wrote: >> >> One big factor against an open source tool chain is that while the FPGA >> vendors describe in general terms the routing inside the devices, the >> precise details are not given, and I suspect that these details may be >> considered as part of the "secret sauce" that makes the device work. The >> devices have gotten so big and complicated, that it is impractical to >> use fully populated muxes, and how you chose what gets to what is >> important. > > I'm not sure what details of routing aren't available. There may not > be a document which details it all, but last I saw, there were chip > level design tools which allow you to see all of the routing and > interconnects. The delay info can be extracted from the timing analysis > tools. As far as I am aware, there is no "secret sauce". > > >> Processors can also have little details like this, but for processors it >> tends to just affect the execution speed, and a compiler that doesn't >> take them into account can still do a reasonable job. For an FPGA, >> without ALL the details for this you can't even do the routing. > > Timing data in an FPGA may be difficult to extract, but otherwise I > think all the routing info is readily available. > My experience is that you get to see what location a given piece of logic, and which channels it travels. You do NOT see which particular wire in that channel is being used. In general, each logic cell does not have routing to every wire in that channel, and every wire does not have access to every cross wire. These details tend to be the secret sauce, as when they do it well, you aren't supposed to notice the incomplete connections. I have had to work with the factory on things like this. I had a very full FPGA and needed to make a small change. With the change I had some over clogged routing, but if I removed all internal constraints the fitter couldn't find a fit. Working with someone who did know the details, we were able to relax just a few internal constraints and get the system to fit the design. He did comment that my design was probably the fullest design he had seen in the wild, we had grown to about 95% logic utilization.Article: 158144
On 8/14/2015 9:32 PM, Richard Damon wrote: > On 8/14/15 1:29 PM, rickman wrote: >> On 8/13/2015 11:17 PM, Richard Damon wrote: >>> >>> One big factor against an open source tool chain is that while the FPGA >>> vendors describe in general terms the routing inside the devices, the >>> precise details are not given, and I suspect that these details may be >>> considered as part of the "secret sauce" that makes the device work. The >>> devices have gotten so big and complicated, that it is impractical to >>> use fully populated muxes, and how you chose what gets to what is >>> important. >> >> I'm not sure what details of routing aren't available. There may not >> be a document which details it all, but last I saw, there were chip >> level design tools which allow you to see all of the routing and >> interconnects. The delay info can be extracted from the timing analysis >> tools. As far as I am aware, there is no "secret sauce". >> >> >>> Processors can also have little details like this, but for processors it >>> tends to just affect the execution speed, and a compiler that doesn't >>> take them into account can still do a reasonable job. For an FPGA, >>> without ALL the details for this you can't even do the routing. >> >> Timing data in an FPGA may be difficult to extract, but otherwise I >> think all the routing info is readily available. >> > > My experience is that you get to see what location a given piece of > logic, and which channels it travels. You do NOT see which particular > wire in that channel is being used. In general, each logic cell does not > have routing to every wire in that channel, and every wire does not have > access to every cross wire. These details tend to be the secret sauce, > as when they do it well, you aren't supposed to notice the incomplete > connections. Don't they still have the chip editor? That *must* show everything of importance. > I have had to work with the factory on things like this. I had a very > full FPGA and needed to make a small change. With the change I had some > over clogged routing, but if I removed all internal constraints the > fitter couldn't find a fit. Working with someone who did know the > details, we were able to relax just a few internal constraints and get > the system to fit the design. He did comment that my design was probably > the fullest design he had seen in the wild, we had grown to about 95% > logic utilization. Yeah, that's pretty full. I start to worry around 80%, but I've never actually had one fail to route other than the ones I tried to help by doing placement, lol. -- RickArticle: 158145
On Friday, August 14, 2015 at 1:32:02 PM UTC-4, rickman wrote: > On 8/14/2015 9:58 AM, KJ wrote: > > On Friday, August 14, 2015 at 9:17:56 AM UTC-4, kaz wrote: > >> > >> I will be interested to see why it doesn't make sense. > > > > "...without grey counter or clock crossing" didn't make much sense sinc= e you still have two clocks and there will still be clock domain crossings.= Those crossings will just occur between domains where there is a specifie= d phase relationship which does open up alternative solutions over situatio= ns where you don't have such a relationship. It's not worth belaboring her= e, sounds like you know what you want to implement. >=20 > I'm not clear on how a clock domain crossing can have any timing=20 > restrictions. Clock domain crossings can be between async clocks which= =20 > can have any phase relationship on any clock edge, varying with each=20 > cycle. So how can you possibly apply timing constraints to that? >=20 Kaz's earlier posts indicated that the two clocks in question had a fixed p= hase relationship so he was going to try to take advantage of that in some = fashion. So there are still multiple clock domains, therefore there are cr= ossings but the two clocks are not truly asynchronous (unless Kaz has been = holding back on his description of the clocks). If the clocks truly have a fixed phase relationship, then a failure that wo= uld occur only one in a bazillion lifetimes if the clocks had been asynchro= nous could tend to show up much more frequently since the failing timing pa= ths could be way more likely to be occurring on almost every clock cycle, n= ot just when the clock phases drifted into just the wrong alignment. KevinArticle: 158146
On 8/14/15 10:59 PM, rickman wrote: > On 8/14/2015 9:32 PM, Richard Damon wrote: >> >> My experience is that you get to see what location a given piece of >> logic, and which channels it travels. You do NOT see which particular >> wire in that channel is being used. In general, each logic cell does not >> have routing to every wire in that channel, and every wire does not have >> access to every cross wire. These details tend to be the secret sauce, >> as when they do it well, you aren't supposed to notice the incomplete >> connections. > > Don't they still have the chip editor? That *must* show everything of > importance. The chip editors tend to just show the LOGIC resources, not the details of the routing resources. The manufactures tend to do a good job of giving the detail of the logic blocks you are working with, as this is the part of the design you tend to specify. Routing on the other hand tends to not be something you care about, just that the routing 'works'. When they have done a good job at designing the routing you don't notice it, but there have been cases where the routing turned out not quite flexible enough and you notice that you can't fill the device as well before hitting routing issues. > > >> I have had to work with the factory on things like this. I had a very >> full FPGA and needed to make a small change. With the change I had some >> over clogged routing, but if I removed all internal constraints the >> fitter couldn't find a fit. Working with someone who did know the >> details, we were able to relax just a few internal constraints and get >> the system to fit the design. He did comment that my design was probably >> the fullest design he had seen in the wild, we had grown to about 95% >> logic utilization. > > Yeah, that's pretty full. I start to worry around 80%, but I've never > actually had one fail to route other than the ones I tried to help by > doing placement, lol. > They suggest that you consider 75-80% to be "Full". This design started in the 70% level but we were adding capability to the system and the density grew. (And were already using the largest chip for the footprint). Our next step was to redo the board and get the usage back down. When we hit the issue we had a mostly working design but were fixing the one last bug, and that was when the fitter threw its fit.Article: 158147
On 8/15/2015 8:32 AM, Richard Damon wrote: > On 8/14/15 10:59 PM, rickman wrote: >> On 8/14/2015 9:32 PM, Richard Damon wrote: >>> >>> My experience is that you get to see what location a given piece of >>> logic, and which channels it travels. You do NOT see which particular >>> wire in that channel is being used. In general, each logic cell does not >>> have routing to every wire in that channel, and every wire does not have >>> access to every cross wire. These details tend to be the secret sauce, >>> as when they do it well, you aren't supposed to notice the incomplete >>> connections. >> >> Don't they still have the chip editor? That *must* show everything of >> importance. > > The chip editors tend to just show the LOGIC resources, not the details > of the routing resources. The manufactures tend to do a good job of > giving the detail of the logic blocks you are working with, as this is > the part of the design you tend to specify. Routing on the other hand > tends to not be something you care about, just that the routing 'works'. > When they have done a good job at designing the routing you don't notice > it, but there have been cases where the routing turned out not quite > flexible enough and you notice that you can't fill the device as well > before hitting routing issues. I'm not sure what details of the routing the chip editors leave out. You only need to know what is connected to what, through what and what the delays for all those cases are. Other than that, the routing does just "work". >>> I have had to work with the factory on things like this. I had a very >>> full FPGA and needed to make a small change. With the change I had some >>> over clogged routing, but if I removed all internal constraints the >>> fitter couldn't find a fit. Working with someone who did know the >>> details, we were able to relax just a few internal constraints and get >>> the system to fit the design. He did comment that my design was probably >>> the fullest design he had seen in the wild, we had grown to about 95% >>> logic utilization. >> >> Yeah, that's pretty full. I start to worry around 80%, but I've never >> actually had one fail to route other than the ones I tried to help by >> doing placement, lol. >> > > They suggest that you consider 75-80% to be "Full". This design started > in the 70% level but we were adding capability to the system and the > density grew. (And were already using the largest chip for the > footprint). Our next step was to redo the board and get the usage back > down. When we hit the issue we had a mostly working design but were > fixing the one last bug, and that was when the fitter threw its fit. The "full" utilization number is approximate because it depends on the details of the design. Some designs can get to higher utilization numbers, others less. As a way of pointing out that the routing is the part of the chip that uses the most space while the logic is smaller, Xilinx sales people used to say, "We sell you the routing and give you the logic for free." The point is the routing usually limits your design rather than the logic. If you want to be upset about utilization numbers, ask them how much of your routing gets used! It's *way* below 80%. -- RickArticle: 158148
On Tuesday, August 18, 2015 at 11:35:55 AM UTC-4, rickman wrote: > > I'm not sure what details of the routing the chip editors leave out. > You only need to know what is connected to what, through what and what > the delays for all those cases are. If you're trying to implement an open source toolchain you would likely need to know *how* to specify those connections via the programming bitstream. KevinArticle: 158149
On 8/18/15 11:35 AM, rickman wrote: > On 8/15/2015 8:32 AM, Richard Damon wrote: >> >> The chip editors tend to just show the LOGIC resources, not the details >> of the routing resources. The manufactures tend to do a good job of >> giving the detail of the logic blocks you are working with, as this is >> the part of the design you tend to specify. Routing on the other hand >> tends to not be something you care about, just that the routing 'works'. >> When they have done a good job at designing the routing you don't notice >> it, but there have been cases where the routing turned out not quite >> flexible enough and you notice that you can't fill the device as well >> before hitting routing issues. > > I'm not sure what details of the routing the chip editors leave out. You > only need to know what is connected to what, through what and what the > delays for all those cases are. Other than that, the routing does just > "work". > Look closely. The chip editor will normally show you the exact logic element you are using with a precise location. The output will then go out into a routing channel and on the the next logic logic cell(s) that it goes to. It may even show you the the various rows and columns of routing it is going through. Those rows and columns are made of a (large) number of distinct wires with routing resources connecting outputs to select lines and select lines being brought into the next piece of routing/logic. Which wire is being used will not be indicated, nor are all the wires interchangeable, so which wire can matter for fitting. THIS is the missing information. > >>>> I have had to work with the factory on things like this. I had a very >>>> full FPGA and needed to make a small change. With the change I had some >>>> over clogged routing, but if I removed all internal constraints the >>>> fitter couldn't find a fit. Working with someone who did know the >>>> details, we were able to relax just a few internal constraints and get >>>> the system to fit the design. He did comment that my design was >>>> probably >>>> the fullest design he had seen in the wild, we had grown to about 95% >>>> logic utilization. >>> >>> Yeah, that's pretty full. I start to worry around 80%, but I've never >>> actually had one fail to route other than the ones I tried to help by >>> doing placement, lol. >>> >> >> They suggest that you consider 75-80% to be "Full". This design started >> in the 70% level but we were adding capability to the system and the >> density grew. (And were already using the largest chip for the >> footprint). Our next step was to redo the board and get the usage back >> down. When we hit the issue we had a mostly working design but were >> fixing the one last bug, and that was when the fitter threw its fit. > > The "full" utilization number is approximate because it depends on the > details of the design. Some designs can get to higher utilization > numbers, others less. As a way of pointing out that the routing is the > part of the chip that uses the most space while the logic is smaller, > Xilinx sales people used to say, "We sell you the routing and give you > the logic for free." The point is the routing usually limits your > design rather than the logic. If you want to be upset about utilization > numbers, ask them how much of your routing gets used! It's *way* below > 80%. > And this is why the keep the real details of the routing proprietary. (Not to keep you from getting upset) The serious design work goes into figuring out how much they really need per cell. If they could figure out a better allocation that let them cut the routing per cell by 10%, they could give you 10% more logic for free. If they goof and provide too little routing, you see the resources that you were sold (since they advertize the logic capability) as being wasted by some 'dumb design limitation'. There have been families that got black eyes of having routing problems, and thus should be avoided for 'serious' work.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z