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
Hi Bob, BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote: >> I started adding false paths to my design (see this thread for a >> context: <boojj9FgihhU1@mid.individual.net>) but in order to avoid funny >> names, I started to add wildcards. [] > > I think you need to do your false path declaration from clock domain to > clock domain, not register to register. There's no clock domain crossing, everything is on the same clock domain. I agree with what Kevin said: you need to track individual paths! I did this simply looking at the critical path reported by the synthesis tool and verifying it was a path involving my (in)famous fpu. I spent 20h of synthesis runs to spot all the paths (essentially 30min each path!), now the problem is that the par is not able to fit timing constraints (clock frequency only). Occupancy level is not huge (60%) so I'm a bit puzzled.Article: 156526
Hi Hans, In comp.arch.fpga HT-Lab <hans64@htminuslab.com> wrote: [] >> I'm considering the possibility to have my model written in SystemC >> while the testbench written in vhdl, leveraging the benefits of the >> OSVVM library. > > That is unusual, I suspect you are better off using SCV as you might hit > some mix language interface issues (records are not always > straightforward on a SC/VHDL interface, use simple structs on SC only). There are two motivations behind this choice: 1. our system engineer is willing to dig into systemC for architecture exploration in the first place. We can profit of the model in order to build our verification environment *soon* in the project. 2. our fpga guys are not so much willing to spend time in learning systemC, while they could feel more confortable with the OSVVM since they know already the language. The first point is a structural element that we are missing in our design flow. Too often the architecture is based on not so well founded choices and as the systems grow more complex, there's an increasing need to get the architecture right at the very beginning. The second point is to enhance our current verification flow which is too often lagging behind. There's an unreasonable perception that going to the bench soon will reveal problems quicker. If we had a reference model and a verification environment early in the project I believe we can shift our mindset and spend less time in testing/debugging the hardware.Article: 156527
Bruce Varley <bv@nospam.com> wrote: > I'm an FPGA newbie, working with the freeware Altera Quartus II IDE. I > used the megafunction builder to create a FIFO memory, the .v file it > generated is similar to the virtual prototypes created for COM interfaces, > with a data structure and no functions. Is this all that the megafunction > builder provides, and I need to write my own Verilog code for eg. bumping > the address registers and generating handshake signals? Or is that code > generated for me already in a file that I haven't found yet? TIA Megafunctions can instantiate internal FPGA structures - so the Megafunction .v just instantiates another module without any actual code, which looks like a prototype. The synthesis tool does however know about this and 'links' it with the right logic. The Megafunction header .v is mostly about declaring the right parameters to the internal module, and also saving the configuration (in comments at the bottom) so you can go in and edit it with the GUI next time. As well as physical hardware blocks, Megafunctions can instantiate private Altera modules or encrypted IP, so you might not be able to see the internals. You can also ask them to make testbenches to try out the function in the simulator. I'd have a look at that first to see what the interface looks like (the manual PDF will also tell you). TheoArticle: 156528
My apologies, I should have really cross-posted this subthread to comp.lang.vhdl as well in the first place. alb <al.basili@gmail.com> wrote: > Hi Hans, > In comp.arch.fpga HT-Lab <hans64@htminuslab.com> wrote: > [] >>> I'm considering the possibility to have my model written in SystemC >>> while the testbench written in vhdl, leveraging the benefits of the >>> OSVVM library. >> >> That is unusual, I suspect you are better off using SCV as you might hit >> some mix language interface issues (records are not always >> straightforward on a SC/VHDL interface, use simple structs on SC only). > > There are two motivations behind this choice: > > 1. our system engineer is willing to dig into systemC for architecture > exploration in the first place. We can profit of the model in order to > build our verification environment *soon* in the project. > > 2. our fpga guys are not so much willing to spend time in learning > systemC, while they could feel more confortable with the OSVVM since > they know already the language. > > The first point is a structural element that we are missing in our > design flow. Too often the architecture is based on not so well founded > choices and as the systems grow more complex, there's an increasing need > to get the architecture right at the very beginning. > > The second point is to enhance our current verification flow which is > too often lagging behind. There's an unreasonable perception that going > to the bench soon will reveal problems quicker. If we had a reference > model and a verification environment early in the project I believe we > can shift our mindset and spend less time in testing/debugging the > hardware.Article: 156529
Hi everyone, we have a license server that hosts both ACTEL_SUMMIT feature (1 seat) and ACTEL_VISTA one (10 seats). Is there a way in Designer to specify either from the command line or through some environment variables the feature I want for a specific session? The two features are forced to be on the same file since lmgrd cannot handle separate files, but it looks like that when I launch the tool the first unassigned feature is used. I haven't seen anything similar in the flexlm documentation and/or the designer command line options. Any pointer is appreciated. Al -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 156530
On 4/14/2014 9:37 PM, KJ wrote: > On Monday, April 14, 2014 8:48:15 PM UTC-4, BobH wrote: >> >> >> I think you need to do your false path declaration from clock domain to >> >> clock domain, not register to register. >> > > Don't think so, the paths are between registers. Saying that every transfer between clock domains is overly pessimistic (based on the OP's posting in the other thread that he referenced). > > Just in general, the bad thing about marking clock domain to clock domain as being a false path rather than individual (or wild carded) paths is that there no check that you don't incorrectly insert such a crossing. If you declare all clock domain crossings to be false, you have nothing in the timing analyzer to check that you haven't overlooked something. If you do declare them by path, then at least you would have had to look at the path at some time and convince yourself that the path is not valid. It's not foolproof but it's better than nothing...unless of course it means that now the design won't build. I don't follow at all. If you have paths between unrelated clocks, they can't be analyzed by STA because there is no clock period to the path. These paths must be correct by design and require special attention separate from STA. Are you saying that by adding them by path you are using STA as your check list to verify that you have caught all such paths? I guess that has some use, but it can be a lot of work and as you say, no guarantee. If it becomes cumbersome as the OP seems to be indicating, I think this can be omitted or perhaps used once to verify your special handling list and then omitted to speed up the rest of the design process. -- RickArticle: 156531
On 4/15/2014 3:40 AM, alb wrote: > Hi Bob, > > BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote: >>> I started adding false paths to my design (see this thread for a >>> context: <boojj9FgihhU1@mid.individual.net>) but in order to avoid funny >>> names, I started to add wildcards. > [] >> >> I think you need to do your false path declaration from clock domain to >> clock domain, not register to register. > > There's no clock domain crossing, everything is on the same clock > domain. > > I agree with what Kevin said: you need to track individual paths! I did > this simply looking at the critical path reported by the synthesis tool > and verifying it was a path involving my (in)famous fpu. > > I spent 20h of synthesis runs to spot all the paths (essentially 30min > each path!), now the problem is that the par is not able to fit timing > constraints (clock frequency only). Occupancy level is not huge (60%) so > I'm a bit puzzled. What is your clock rate? What part of the design is failing timing? I thought you were going to set the timing of the FPU to match what the tools would produce... Are you saying the non-FPU portion of the design is failing timing? -- RickArticle: 156532
On Tuesday, April 15, 2014 12:46:02 PM UTC-4, rickman wrote: > > Just in general, the bad thing about marking clock domain to clock doma= in as=20 > > being a false path rather than individual (or wild carded) paths is tha= t=20 > > there no check that you don't incorrectly insert such a crossing. If y= ou=20 > > declare all clock domain crossings to be false, you have nothing in the= =20 > > timing analyzer to check that you haven't overlooked something. If you= do=20 > > declare them by path, then at least you would have had to look at the p= ath at=20 > > some time and convince yourself that the path is not valid. It's not= =20 > > foolproof but it's better than nothing...unless of course it means that= now=20 > > the design won't build.=20 > I don't follow at all. If you have paths between unrelated clocks, they= =20 > can't be analyzed by STA because there is no clock period to the path.=20 You can have them analyzed. Other than to point out where this is a crossi= ng though I'm not sure how to really interpret the results that come out si= nce it would depend on the relative phases and the frequencies of the clock= s. But I don't care about that, just the list of paths that cross. > These paths must be correct by design and require special attention=20 > separate from STA.=20 Agreed. But there is still value in putting something in place to verify w= hether you are 'correct by design' or if something slipped through the crac= ks. > Are you saying that by adding them by path you are using STA as your=20 > check list to verify that you have caught all such paths? I guess that= =20 > has some use, but it can be a lot of work and as you say, no guarantee.= =20 Yes, I use it as a check that there are no new paths created that cross dom= ains. It's not a lot of work since there aren't a boatload of places where= signals cross clock domains in the first place. There may be no guarantee= , but it is an additional check that gets performed on every build. Of cou= rse, within a clock domain and for the I/O pins, I'm using the full STA res= ults. > If it becomes cumbersome as the OP seems to be indicating, I think=20 > this can be omitted or perhaps used once to verify your special handling= =20 > list and then omitted to speed up the rest of the design process I can't say I have any idea what is going in the OP's case. I wildcard spe= cify paths so while I have a handful of path constraints I really don't kno= w how many actual paths that explodes to. I haven't had those constraints = have any dramatic impact on P&R time like the OP is seeing. Kevin JenningsArticle: 156533
Hi Al, I always considered the false path declaration to be useful for handling multiple clock domain issues, or getting the tool chain to ignore the scan clock (or scan enable) to normal clock interaction type problems. With a single clock domain, using the false path won't work from clock to clock. If you are getting 60K expansions on 50 nets, maybe reducing the wildcarding would help. Is all of your clock distribution on one of the global clock routing resources? Are you using clock gating? 60% utilization should not be forcing the P&R tool into choices that have problems. Do you have the I/O pins constrained? If so, releasing the pin constraints and letting the tool pick them is a useful troubleshooting method. This is about all the ideas I have at this point. Good Luck, BobH On 4/15/2014 12:40 AM, alb wrote: > Hi Bob, > > BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote: >>> I started adding false paths to my design (see this thread for a >>> context: <boojj9FgihhU1@mid.individual.net>) but in order to avoid funny >>> names, I started to add wildcards. > [] >> >> I think you need to do your false path declaration from clock domain to >> clock domain, not register to register. > > There's no clock domain crossing, everything is on the same clock > domain. > > I agree with what Kevin said: you need to track individual paths! I did > this simply looking at the critical path reported by the synthesis tool > and verifying it was a path involving my (in)famous fpu. > > I spent 20h of synthesis runs to spot all the paths (essentially 30min > each path!), now the problem is that the par is not able to fit timing > constraints (clock frequency only). Occupancy level is not huge (60%) so > I'm a bit puzzled. >Article: 156534
Hi all I'm usinf Digilent Nexys 4 FPGA BOard and I won't to run LInux kernel on microblaze and I don't have a lot of information to complete this project . Can anyone help me (link,tutoriel, help ) THanks Best regardsArticle: 156535
On Mon, 14 Apr 2014 06:43:38 -0700 (PDT), KJ <kkjennings@sbcglobal.net> wrote: >On Monday, April 14, 2014 9:17:25 AM UTC-4, Bruce Varley wrote: >> I'm an FPGA newbie, working with the freeware Altera Quartus II IDE. I used the >> megafunction builder to create a FIFO memory, the .v file it generated is >> similar to the virtual prototypes created for COM interfaces, with a data >> structure and no functions. Is this all that the megafunction builder provides, >> and I need to write my own Verilog code for eg. bumping the address registers >> and generating handshake signals? Or is that code generated for me already in a >> file that I haven't found yet? TIA > >Quartus has a megafunction for a FIFO, it is under 'Memory Compiler' that has a typical FIFO interface set of signals. Which megafunction part are you using? > >Kevin Jennings DCFIFO, double clocked FIFO. Using the wizard was straightforward, but after that I'm not sure whether I need to implement the glue logic, such as the memory address incrementing and rollaround. Sounds like I don't (once I work out what to do to make it happen). Thanks for responses.Article: 156536
Has anyone come across an issue where an XC3S200 is recognised in Impact; "Right Click to Add Device or Initialize JTAG chain", and then can't read the device ID, status or indeed do anything else. Power supplies on the board look good. Changed device and still the same problem. Will investigate more later, but any ideas? It can only be something stupid!! -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 156537
W dniu 2014-04-17 12:50, Mike Perkins pisze: > Has anyone come across an issue where an XC3S200 is recognised in > Impact; "Right Click to Add Device or Initialize JTAG chain", and then > can't read the device ID, status or indeed do anything else. > > Power supplies on the board look good. Changed device and still the same > problem. > > Will investigate more later, but any ideas? It can only be something > stupid!! > Like too long jtag cable together with too fast jtag clock speed. You must ensure good clock edge quality. Best regards AdamArticle: 156538
unable to solve this error.I tried all the thing and check that there is no duplicate module..still its giving error..any one can help???plzArticle: 156539
On Saturday, 1 March 2014 13:34:01 UTC+1, Brane2 wrote: > I'm playing with Lattice's MachXO2 and ECP3 for a few months now and now that MachXO3 is about to come out I wonder what happened to ECP4. > > > > As I understand it, Lattice found its market niche in low-power/low-cost branch, especially now when they bought BlueSilicon and incprporated their program in ice40 series. > > > > Knowing that they try to keep the cost down by using one process for all of their models and that MachXO2/ECP3 were done on 65 nm, while new ice40 and MachXO3 are on 40nm node, one would expect to see their high-end ECP4 on 40nm, too. > > > > If main selling point of ECP3 was as cheapest FPGA with fast transceivers, this is diminishing now as MachXO3 will get those, too ( beside other upgrades). > > > > But there is nothing on ECP4. Googling around shows 2 year old failed launch ( they obviously changed their mind) and nothing more. > > > > Will there be ECP4 on 40nm and if so, what will be the update - faster transceivers or perhaps some cool ( preferably MIPS) core hardmacro onboard? > > > > Or is Xilinx pushing too hard on that part of the market with Spartan-6 ? > > > > I know there isn't anything official on the matter, I'm looking for more or less substantiated rumours... Well in breaking news: ECP5 has been announced (on a 40 nm process)!Article: 156540
Dne petek, 18. april 2014 08:38:50 UTC je oseba ajp...@gmail.com napisala: > > > Well in breaking news: ECP5 has been announced (on a 40 nm process)! ECP5 announcement is out probably for a few weeks now. It feels as trimmed down as new MahXO3L is against old MachXO2. When I complained about this, Lattice basically hinted everyone tho chill out. MachXO3L is tweaked and parred for their biggest customers, probably for some tablets, phones etc etc. MachXO3H is yet to come. And it seems like it's that way with ECP5. It's basically just redone for 40nm. And I keep hearing those rumours about "Sapphire", so that might be it- something like ECP5-H(igh end)Article: 156541
For those interested in MachXO: MachX03L seems almost the same as MachXO2. At least I couldn't find any difference. And as I checked it against MachXO2 pricewise on Digikey, they came out the same. Until someoneone pointed to "thingie" with FLASH. MachXO3L doesn't have the same FLASH block as MachXO2 does. XO2 is reprogrammable 10.000x with data retention of 10yr. XO3L is reprogrammable _TWICE_ Or as Lattice calls it "Multi time reprogramable". With multi = 2. But as said, this is just XO3L - XO3 part for extreme cheapscates ;o)Article: 156542
>unable to solve this error.I tried all the thing and check that there is no duplicate module..still its giving error..any one can help???plz > I'm sure we could if we had access to the hdl source code. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 156543
On 17/04/2014 11:50, Mike Perkins wrote: > Has anyone come across an issue where an XC3S200 is recognised in > Impact; "Right Click to Add Device or Initialize JTAG chain", and then > can't read the device ID, status or indeed do anything else. > > Power supplies on the board look good. Changed device and still the same > problem. > > Will investigate more later, but any ideas? It can only be something > stupid!! Yes - very stupid. It seems you can initialise a chain without TDI connected. Connected TDI and all's well. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 156544
http://hansvi.be/wordpress/?p=91 -- Les CargillArticle: 156545
My .v Verilog source files were in a separate folder to the IDE build directory, containing all the stuff generated in the build. Then I had a hard disk crash, and (long story) everything *except* the .v source has been recoverable, for one, relatively small project. Is there any way that I can back build the source from the various files that the IDE (Altera Quartus II) creates? Even a partial reconstruction would help, ie. I'm prepared to do some manual fossicking. There isn't any ascii listing that I can find, everything is either binary, or tabular stuff such as pin data.Article: 156546
I am designing my own Altera Cyclone V SoM board. It is not intended to be a dev board. It will be a function module that also includes Analog Devices' SHARC DSPs. I am working on the JTAG connection strategy. It seems to me that separate JTAG connections make more sense than chaining since Quartus may be running separately from the ARM (HPS). Unless someone tells me something different, my plan is to use a pair of 2mm 2x5 headers, one for the FPGA and the other for the HPS. These would be identical to the Altera pinouts, just smaller. I expect that the board will be running uLinux, probably GCC. Here are my questions: 1. I know that many of the Altera Cyclone V dev boards use a USB Blaster 2 circuit. Does anyone sell a USB Blaster 2 download cable? I have lots of USB Blaster clones already. 2. What should I do about the HPS TRST#. It is not supported on the USB Blaster? 3. The HPS Trace connections might be useful but these are needed for their alternate I/O functions. I am assuming that the Mictor interface will not be that helpful. I would appreciate any other comments or insight. Al --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.comArticle: 156547
Hi Kevin, KJ <kkjennings@sbcglobal.net> wrote: [] > I can't say I have any idea what is going in the OP's case. I > wildcard specify paths so while I have a handful of path constraints I > really don't know how many actual paths that explodes to. I haven't > had those constraints have any dramatic impact on P&R time like the OP > is seeing. At least Synplify Pro generates an 'sdc' file with the expanded signals out of your wildcards. It seems to me the file is automagically generated so no need to specify anything special in your settings. A simple: grep set_false_path file.sdc | wc -l will do the trick (on a *nix system).Article: 156548
Hi Rick, rickman <gnuarm@gmail.com> wrote: >> I spent 20h of synthesis runs to spot all the paths (essentially 30min >> each path!), now the problem is that the par is not able to fit timing >> constraints (clock frequency only). Occupancy level is not huge (60%) so >> I'm a bit puzzled. > > What is your clock rate? What part of the design is failing timing? I > thought you were going to set the timing of the FPU to match what the > tools would produce... Are you saying the non-FPU portion of the design > is failing timing? After my last 56hours run and some easter eggs (no pun intended) in between, I've realized there are additional paths of my FPU which were ok during synthesis but failed after p&r. I guess now I need to add additional false paths after they have been flagged as failing after p&r... I have to say that this is an endless story and I'm not sure where it is going to get me. After all those hours I guess now it would have been more reliable and less painful to pipeline the design (sigh!). AlArticle: 156549
Hi Bob, BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote: [] > I always considered the false path declaration to be useful for handling > multiple clock domain issues, or getting the tool chain to ignore the > scan clock (or scan enable) to normal clock interaction type problems. Please refer to my other thread on 'path verification' to follow the insanity of what I've been asked to do. > With a single clock domain, using the false path won't work from clock > to clock. false paths are from clock to D. > If you are getting 60K expansions on 50 nets, maybe reducing the > wildcarding would help. Uhm, I do not think I have much of a choice if I do not want to change the constraint file over and over again. > > Is all of your clock distribution on one of the global clock routing > resources? Are you using clock gating? I haven't done any check about the clock beeing used on a single clock routing resource, but I guess is not since typically those chips are devided in quadrants and each quadrant has its own clock resource. I'm not sure if I need to pay extra attention to quadrant crossing clocks... > > 60% utilization should not be forcing the P&R tool into choices that > have problems. Do you have the I/O pins constrained? If so, releasing > the pin constraints and letting the tool pick them is a useful > troubleshooting method. There are no I/O pins at all, the design is meant to be used as a block since we cannot afford to re-do the exercise everytime we integrate the module within another project. > This is about all the ideas I have at this point. Thanks for sharing them. Al
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