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
On Sep 14, 2:54 pm, KJ <Kevin.Jenni...@Unisys.com> wrote: > On Sep 14, 3:57 am, GaLaKtIkUs=99 <taileb.me...@gmail.com> wrote:> Hi, > > Is the post place&route simulation so important? > > IMHO doing post synthesis (or post translate) simulation for verifying > > behavior than doing a post place and route static timing analysis is > > sufficient and less resource consuming than doing a timing simulation. > > Once one is sufficiently skilled I would agree....at least for FPGA > designs. For ASICs where the cost for fixing an error is much, much > higher one might have a different opinion. > > > Moreover if errors are found during timing simulations (by errors I > > mean X or false results) they are almost always (for my cases) > > difficultly traceable. > > Which sounds like you're maybe not quite there on the 'sufficiently > skilled' front since you still get 'X' or false results. Definitely a > pain in the rear to trace back to the root cause through the post- > route sim I agree. What I meant is that if I see X or errors in post place and route simulation than fixing them is almost impossible in reasonable time (for me). But if I do timing analysis and fix all errors than do timing simulation than the timing is true. So to reformulate clearly: Is it sufficient yo do post-synthesis simulation (of course after having validated the design by behavioral simulation) + static timing simulation to guarantee working design? in other words is it possible to skip timing simulation this way?Article: 124201
"Petter Gustad" <newsmailcomp6@gustad.com> wrote in message news:87abrqb8b8.fsf@gustad.com... > "cpope" <cepope@nc.rr.com> writes: > > > from. I am running Linux on the PPC inside the FX12 so I'm thinking > > How do you get the bitstream (xsvf or whatever) into the FX12? > > Petter > -- > 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? I'm running a linux OS so I have several options: ftp, usb thumb drive, or serial. I am worried about the size of the svf file as I only have about 32MB free space internal. -ClarkArticle: 124202
"Andrew Greensted" <ajg112@ohm.york.ac.uk> wrote in message news:fcdo4g$au9$1@netty.york.ac.uk... > > Could someone just check the following for me: > > PROG_B driven by AVR needs to be 2.5V logic > DIN driven by AVR 3.3V logic (I think) > CCLK driven by AVR 3.3V logic > > INIT_B driven by FPGA 3.3V logic > DONE driven by FPGA 2.5V logic > DOUT driven by FPGA 3.3V logic > > Many thanks > Andy Hi Andy, That's what I did on my last S3E design. I pulled PROG_B low through a schottky diode with a pullup to 2.5V at the FPGA. All that said, I would rely on the datasheet more than usenet! HTH, Syms.Article: 124203
On 14 Sep, 13:10, "cpope" <cep...@nc.rr.com> wrote: > "Petter Gustad" <newsmailco...@gustad.com> wrote in message > > news:87abrqb8b8.fsf@gustad.com... > > > "cpope" <cep...@nc.rr.com> writes: > > > > from. I am running Linux on the PPC inside the FX12 so I'm thinking > > > How do you get the bitstream (xsvf or whatever) into the FX12? > > > Petter > > -- > > 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? > > I'm running a linux OS so I have several options: ftp, usb thumb drive, or > serial. I am worried about the size of the svf file as I only have about > 32MB free space internal. > > -Clark There is one nice advantage of using the jdrive for the XCFxxP devices, and that is the erase time. For the XSVF/SVF player there is a fixed erase time of 140 seconds, which is the maximum time it can take to erase an XCF32P. The jdrive software can sit in a loop polling a bit to see when the erase really completes, if you look in the IEE1532 BSDL file for the XCFxxP device you will see what I mean. There is also a similar issue with the programming time, but since that is a much shorter delay you don't notice it quite so much. Neill.Article: 124204
Symon wrote: > Hi Andy, > That's what I did on my last S3E design. I pulled PROG_B low through a > schottky diode with a pullup to 2.5V at the FPGA. > All that said, I would rely on the datasheet more than usenet! > HTH, Syms. Cheers Symon, My plan was to use one of those tiny-logic single gates, they've got 5V tolerant inputs and can be by 2.5V. That should do the level conversion nicely. Andy -- Dr. Andrew Greensted Department of Electronics Bio-Inspired Engineering University of York, YO10 5DD, UK Tel: +44(0)1904 432828 Mailto: ajg112@ohm.york.ac.uk Fax: +44(0)1904 432335 Web: http://www.bioinspired.com/users/ajg112Article: 124205
GaLaKtIkUsā¢ wrote: > Is the post place&route simulation so important? > IMHO doing post synthesis (or post translate) simulation for verifying > behavior than doing a post place and route static timing analysis is > sufficient and less resource consuming than doing a timing simulation. I'd say that both simulations are usually not necessary with FPGAs. RTL simulations and STA analysis should be enough almost all the time. Netlist simulations verify the synthesizer and timing constraints. Formal equivalence checking might be faster way to verify RTL->netlist synthesis results. And usually for FPGA the timing constraints are not as complicated as with ASIC (no need for the process variation analysis etc.) > Moreover if errors are found during timing simulations (by errors I > mean X or false results) they are almost always (for my cases) > difficultly traceable. That is the problem with netlists. I have spent weeks wondering what happens inside ASIC netlists, where the X propagates and how to fix them. NRE for ASIC is so high that netlist simulations are important, but just for timing constraint verification, and to catch stupid errors that are related to IO and test structures that are inserted in by automatic tools. --KimArticle: 124206
"cpope" <cepope@nc.rr.com> writes: > I'm running a linux OS so I have several options: ftp, usb thumb > drive, or serial. I am worried about the size of the svf file as I > only have about 32MB free space internal. Then you could program on the fly as you transfer the data using any of the above methods. Petter -- 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: 124207
LowSNR wrote:
> I've been doing some development work over the past year or so on the
> Atmel FPSLIC platform. I've run out of time on the license for the
> Mentor software that came with the dev kit ...
The choices I see are change platforms or buy a license.
-- Mike Treseler
Article: 124208GaLaKtIkUs wrote: > Is the post place&route simulation so important? Not so much for synchronous designs on FPGAs. > ... doing post synthesis (or post translate) simulation for verifying > behavior ... A gate level sim tells me nothing about behavior that I didn't learn from my code sim. It may be a valid check-off item at release time for the reasons that Kim mentioned. .. then doing a post place and route static timing analysis This is essential. > ... less resource consuming than doing a timing simulation. and STA finds all timing problems, where a timing sim is lucky to find any. > Moreover if errors are found during timing simulations (by errors I > mean X or false results) they are almost always (for my cases) > difficultly traceable. Yes, and the root cause is almost always the testbench or a vendor sim model, -- Mike TreselerArticle: 124209
Kim makes an excellent point: timing constraints are the biggest reason for an experienced designer to run (or not run) post-route timing simulations. While most clock and IO constraints are pretty straight forward and seldom cause a problem, false-path and multi- cycle constraints are easily specified erroneously, and lacking specialized formal tools to check/generate them, the only way to verify them is with post-route timing simulations. For that reason, If I don't need a multicycle or false path constraint, I don't use it. I will put in a significant level of extra work in the implementation to avoid them if necessary, and thus avoid the need for post-route simulations. That said, novice designers should run post-synthesis or post-route simulations just to make sure they're not doing something stupid in their synthesizable code. By focusing on much faster RTL simulations (especially if you use integers, variables, and only clocked processes wherever possible), more "corner cases" can be covered in less time. This should be obvious, but Static Timing Analysis is mandatory, regardless of whether you run a full timing simulation. Also, this holds for FPGA development where the cost of failure is usually rather low, compared to ASICs. That said, there are some rather expensive OTP FPGAs that would fall more under the ASIC verification model, where full timing simulations are justified by the NRE to fix a problem during hardware test/integration. You have to ask yourself what kind of problems you are trying to detect/prevent: design specification problems, verification problems, tool problems (simulation, synthesis, P&R, STA, etc.), and what are their relative probabilities as well as cost of detection vs cost of repair? AndyArticle: 124210
acd wrote:
> Would FPGAs have been successfull, if they had been implemented with
> vanilla CMOS gates and latches?
They wouldn't have been programmable.
-- Mike Treseler
Article: 124211Originally, FPGA had to overcome the "to small, too slow, too expensive" criticism, and had to use every possible circuit trick to become more efficient. Replacing ASICs came later, when size, speed and cost had become competitive with some ASIC applications. If we had not pulled all the stops to become efficient, we might now be a footnote in history,,, Horribile dictu. Peter Alfke On Sep 14, 8:29 am, Mike Treseler <mike_trese...@comcast.net> wrote: > acd wrote: > > Would FPGAs have been successfull, if they had been implemented with > > vanilla CMOS gates and latches? > > They wouldn't have been programmable. > > -- Mike TreselerArticle: 124212
On 14 Sep., 17:29, Mike Treseler <mike_trese...@comcast.net> wrote: > acd wrote: > > Would FPGAs have been successfull, if they had been implemented with > > vanilla CMOS gates and latches? > > They wouldn't have been programmable. > > -- Mike Treseler Meant also to Peter: Mike, either I did miss your irony or you did get me wrong: Of course one could implement an FPGA with vanilla CMOS latches and gates, build your configuration registers with standard latches, build the LUT-readout multiplexer with standard gates, build the routing with combinational multiplexers and standard latches. I guess, the Algotronix (later Xilinx 6200) devices would have been more friendly for this, than the Xilinx 2000 devices, but it could be done. You would just need way more transistors. My assumption was that if Xilinx/AMD/Lattice & Co. would have done it this way, the capacity/cost would have been so poor that the FPGA business had never taken off, or at least much weaker and later. Peter kind of confirmed that assumption, thanks. AndreasArticle: 124213
<neilla@pipstechnology.co.uk> wrote in message news:1189772963.643390.40040@22g2000hsm.googlegroups.com... > On 14 Sep, 13:10, "cpope" <cep...@nc.rr.com> wrote: > > "Petter Gustad" <newsmailco...@gustad.com> wrote in message > > > > news:87abrqb8b8.fsf@gustad.com... > > > > > "cpope" <cep...@nc.rr.com> writes: > > > > > > from. I am running Linux on the PPC inside the FX12 so I'm thinking > > > > > How do you get the bitstream (xsvf or whatever) into the FX12? > > > > > Petter > > > -- > > > 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? > > > > I'm running a linux OS so I have several options: ftp, usb thumb drive, or > > serial. I am worried about the size of the svf file as I only have about > > 32MB free space internal. > > > > -Clark > > There is one nice advantage of using the jdrive for the XCFxxP > devices, and that is the erase time. For the XSVF/SVF player there is > a fixed erase time of 140 seconds, which is the maximum time it can > take to erase an XCF32P. The jdrive software can sit in a loop > polling a bit to see when the erase really completes, if you look in > the IEE1532 BSDL file for the XCFxxP device you will see what I mean. > There is also a similar issue with the programming time, but since > that is a much shorter delay you don't notice it quite so much. > > Neill. > Has anyone looked at xapp975 from xilinx? This is a lightweight version of the programming which claims to not have the erase problem you cite. Would be perfect for my application except: 1. the xcf32p has to be on its own jtag chain - how many times would you have that in a design? 2. the byte interface is not very friendly - would work better if they made it an OPB peripheral 3. revisioning is not supported I'm still going to pursue it as I expect all of these issues could be resolved, it's just that the first version of this came out last month. -ClarkArticle: 124214
acd wrote:
> Mike, either I did miss your irony or you did get me wrong:
Neither, although I suppose that everything
I say and do is ironic at some level.
The expensive part of an ASIC isn't the
gates and flops, it's the wires.
The big idea that eventually made FPGAs successfully
is programmable wires. Wherever I am on the chip
I can pick up a low skew clock with no effort
on my part. That's the special sauce.
-- Mike Treseler
Article: 124215I am trying to do a Virtex4 design, I have completed the post synthesis (XST) simulations in Modelsim - everything appears fine. When I run the PAR and simulate the generated model. I get all zeros on the output. None of the registers in the desing appear to be loading. I have specified the timing constraints for the period of the clock (only that constraint). Is there something I may be forgetting to do? My desing is runnig at 125Mhz. ThanksArticle: 124216
Mike Treseler wrote:
> The big idea that eventually made FPGAs successfully
successful
Next big idea: A smart spell checker.
Article: 124217Andrew Greensted wrote: > > Could someone just check the following for me: > > PROG_B driven by AVR needs to be 2.5V logic > DIN driven by AVR 3.3V logic (I think) > CCLK driven by AVR 3.3V logic > > INIT_B driven by FPGA 3.3V logic > DONE driven by FPGA 2.5V logic > DOUT driven by FPGA 3.3V logic > Have a look at pages 101-121 of: http://www.xilinx.com/products/spartan3e/sp3e_power.pdf This info may have all percolated into the datasheet by now, but that's still a most useful document. BrianArticle: 124218
Hi, I have a question on Synplicity synthesis / FPGA synthesis. Is there a way to give in the `defines from the command lines in synplicity synthesis .. something like add_file -verilog +define ..... filename.v I am not sure if it's +define or something else, so thought of giving this querty to the group. I have researched this stuff in the user and reference manual but couldn't find a link. Any kinda help is appreciated. Thanks!Article: 124219
That's a nice walkthrough but doesn't address the issue of incorporating hardware designs. > http://www.itee.uq.edu.au/~wu/downloads/uClinux_ready_Microblaze_design.pdfArticle: 124220
On Sep 14, 3:59 am, acd <acd4use...@lycos.de> wrote: > CPLDs and FPGAs both make (or made) use of "non-standard" > implementation > of digital circuits, namely wired-OR and pass-transistors. > Both techniques are much more difficult to use in standard cell ASICs > or gate arrays. > Therefore, one could argue that the use of these methods reduced the > area and speed > overhead induced by the programmability. > So while many ASICs that have been replaced by FPGAs would not have > used the methods, > the CPLDs/FPGAs did. > > How strong do you think was and is this effect? > Would FPGAs have been successfull, if they had been implemented with > vanilla CMOS > gates and latches? > Or better, how much smaller the success story of FPGAs would have > been > without the use of pass transistors in LUTs and routing? > > Andreas I think you're confusing the product of an ASIC and an FPGA. ASICs are limited to "standard" cell devices, because the tools have to be easily applicable (and verifiable!) to a wide variety of situations. An FPGA (the virgin part, not the programmed application) is more like a high-end processor, with much larger volumes to support dedicated designs using "non-standard" features. I'm sure you'd find similar tricks in any large, high-volume, fully custom, digital IC. No major processor would survive in the market without similar tricks either. AndyArticle: 124221
jkrauss@lowsnr.com wrote: > I've been doing some development work over the past year or so on the > Atmel FPSLIC platform. I've run out of time on the license for the > Mentor software that came with the dev kit, If the dev kit is less expensive than the Mentor license, you could buy another dev kit.Article: 124222
"Andy" <jonesandy@comcast.net> wrote in message news:1189783145.694707.69630@o80g2000hse.googlegroups.com... > Kim makes an excellent point: timing constraints are the biggest > reason for an experienced designer to run (or not run) post-route > timing simulations. While most clock and IO constraints are pretty > straight forward and seldom cause a problem, false-path and multi- > cycle constraints are easily specified erroneously, and lacking > specialized formal tools to check/generate them, the only way to > verify them is with post-route timing simulations. Focus from Fishtail will find most MCP and FP's in your design and generate a bunch of PSL/SVA assertions to verify them. Assertions are great for validating MCP/FP's. If you are a burn and go kind of engineer than you can use Temento's Dialite to convert your MCP/FP assertions into hardware monitors and check that during hardware testing none of them triggers. > > For that reason, If I don't need a multicycle or false path > constraint, I don't use it. > I will put in a significant level of extra > work in the implementation to avoid them if necessary, and thus avoid > the need for post-route simulations. > > That said, novice designers should run post-synthesis or post-route > simulations just to make sure they're not doing something stupid in > their synthesizable code. I would also add that gatelevel (structural) can be useful if your design is not working on "the board" (STA is all happy) since the whole chain from RTL to bitstream is not flawless and bad logic can be introduced during any of the intermediate stages. I know that gatelevel simulation is dead slow especially if you are using Vital but sometimes you need to run a gatelevel simulation to answer the above question. > > By focusing on much faster RTL simulations (especially if you use > integers, variables, and only clocked processes wherever possible), > more "corner cases" can be covered in less time. > > This should be obvious, but Static Timing Analysis is mandatory, > regardless of whether you run a full timing simulation. > > Also, this holds for FPGA development where the cost of failure is > usually rather low, compared to ASICs. That said, there are some > rather expensive OTP FPGAs that would fall more under the ASIC > verification model, where full timing simulations are justified by the > NRE to fix a problem during hardware test/integration. That reminds me of my first Radition Tolerant 1020 from Actel, at £1000 a pop (10 years ago) ...... those were the days of real FPGA's :-) > > You have to ask yourself what kind of problems you are trying to > detect/prevent: design specification problems, verification problems, > tool problems (simulation, synthesis, P&R, STA, etc.), and what are > their relative probabilities as well as cost of detection vs cost of > repair? Good point! Hans www.ht-lab.com > > Andy >Article: 124223
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in message news:5kuvpsF5kqemU1@mid.individual.net... >> I'm assuming from all this, that we're talking about interfacing to >> async memory. If so, then what you suggest will possibly fail timing >> because of a race condition between the write strobe going inactive >> and the address starting to change. So just exactly when would you be >> strobing the write signal itself? > > You wouldn't, if you'd read the thread you'd have seen that the write > strobe is being held active and the (grey coded) address change is being > used to action the write.... > I read the thread but admit I did forgot the point about always writing to the SRAM. For 'every clock cycle' read/write to SRAMs applications, I like the following http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=6&f=G&l=50&co1=AND&d=PTXT&s1=Jennings.INNM.&s2=Unisys.ASNM.&OS=IN/Jennings+AND+AN/Unisys&RS=IN/Jennings+AND+AN/Unisys > > I've never tried this in anger because no sram data sheet that I could > find had any information on whether this mechanism would work, it was > just an idea on how to stream data into an external SRAM faster. > Agreed, you'd probably have to get some more info from the SRAM suppliers to see if it would really work. KJArticle: 124224
>Originally, FPGA had to overcome the "to small, too slow, too >expensive" criticism, and had to use every possible circuit trick to >become more efficient. >Replacing ASICs came later, when size, speed and cost had become >competitive with some ASIC applications. >If we had not pulled all the stops to become efficient, we might now >be a footnote in history,,, >Horribile dictu. >Peter Alfke Similar to Fortran, which was competing with hand-coded assembler and had to produce really good code. -- mac the naļf
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