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 Oct 3, 9:54 am, "Tom Lucas" <news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk> wrote: > "ratemonotonic" <niladri1...@gmail.com> wrote in message > > news:1191349922.467508.71410@d55g2000hsg.googlegroups.com... > > > > > > > On 2 Oct, 19:09, "Michael N. Moran" <mnmo...@bellsouth.net> wrote: > >> Mike Treseler wrote: > >> > 1. A simulator to verify and debug > >> > the uut and testbench code and > > >> I've recently been learning VHDL myself and have > >> found GHDL to be quite useful and *free* with-out > >> all that dreadful IDE stuff. Combined with gtkwave > >> under Linux, it is a nice little system. ymmv. > > >> <http://ghdl.free.fr/> > > >> -- > >> Michael N. Moran (h) 770 516 7918 > >> 5009 Old Field Ct. (c) 678 521 5460 > >> Kennesaw, GA, USA 30144 http://mnmoran.org > > >> "So often times it happens, that we live our lives in chains > >> and we never even know we have the key." > >> "Already Gone" by Jack Tempchin (recorded by The Eagles) > > >> The Beatles were wrong: 1 & 1 & 1 is 1 > > > Try this out for really cheap boards for beginners - > > >http://www.knjn.com/ > > The Pluto 3 looks like just the thing. Are they available from a UK > supplier or do I need to look at getting one imported? > > > > > also try this for some "fun projects" - > > >http://www.fpga4fun.com/- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - Has to be shipped to UK. see - http://www.knjn.com/ShopInfo.html From news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk Wed Oct 03 02:30:31 2007 Path: newsdbm05.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!goblin1!goblin.stu.neva.ru!eweka.nl!hq-usenetpeers.eweka.nl!195.245.201.2.MISMATCH!news.clara.net!wagner.news.clara.net!despina.uk.clara.net From: "Tom Lucas" <news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk> Newsgroups: comp.arch.embedded,comp.arch.fpga References: <1191335877.22751.0@proxy01.news.clara.net> <5mfbenFd8h6cU1@mid.individual.net> <BPvMi.24$i7.14@bignews2.bellsouth.net> <1191349922.467508.71410@d55g2000hsg.googlegroups.com> <1191401543.28797.0@despina.uk.clara.net> <1191402057.403464.242310@o80g2000hse.googlegroups.com> Subject: Re: Basic VHDL Development kit Date: Wed, 3 Oct 2007 10:30:31 +0100 Lines: 62 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-RFC2646: Format=Flowed; Original X-Complaints-To: abuse@clara.net (please include full headers) X-Trace: 68c80404127871605c615996405068692310600578df603d5f6a0a90470360ce NNTP-Posting-Date: Wed, 03 Oct 2007 10:28:46 +0100 Message-Id: <1191403726.29506.0@despina.uk.clara.net> Xref: prodigy.net comp.arch.embedded:260407 comp.arch.fpga:136714 "ratemonotonic" <niladri1979@gmail.com> wrote in message news:1191402057.403464.242310@o80g2000hse.googlegroups.com... > On Oct 3, 9:54 am, "Tom Lucas" > <news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk> wrote: >> "ratemonotonic" <niladri1...@gmail.com> wrote in message >> >> news:1191349922.467508.71410@d55g2000hsg.googlegroups.com... >> >> >> >> >> >> > On 2 Oct, 19:09, "Michael N. Moran" <mnmo...@bellsouth.net> wrote: >> >> Mike Treseler wrote: >> >> > 1. A simulator to verify and debug >> >> > the uut and testbench code and >> >> >> I've recently been learning VHDL myself and have >> >> found GHDL to be quite useful and *free* with-out >> >> all that dreadful IDE stuff. Combined with gtkwave >> >> under Linux, it is a nice little system. ymmv. >> >> >> <http://ghdl.free.fr/> >> >> >> -- >> >> Michael N. Moran (h) 770 516 7918 >> >> 5009 Old Field Ct. (c) 678 521 5460 >> >> Kennesaw, GA, USA 30144 http://mnmoran.org >> >> >> "So often times it happens, that we live our lives in chains >> >> and we never even know we have the key." >> >> "Already Gone" by Jack Tempchin (recorded by The Eagles) >> >> >> The Beatles were wrong: 1 & 1 & 1 is 1 >> >> > Try this out for really cheap boards for beginners - >> >> >http://www.knjn.com/ >> >> The Pluto 3 looks like just the thing. Are they available from a UK >> supplier or do I need to look at getting one imported? >> >> >> >> > also try this for some "fun projects" - >> >> >http://www.fpga4fun.com/- Hide quoted text - >> >> - Show quoted text -- Hide quoted text - >> >> - Show quoted text - > > Has to be shipped to UK. > > see - > > http://www.knjn.com/ShopInfo.html $10 seems reasonable enough for shipping. Hopefully my credit card won't sting me for using foreign currency.Article: 124751
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:1190990042.490029.3360@w3g2000hsg.googlegroups.com... > Hi > > I am evaluating the possibility to use 2 resitor video output from > FPGA similar to: > > http://www.excamera.com/articles/15/ntsc.html > > to generate color NTSC output, Antti, you'll only be able to generate a black and white signal with this technique. For colour you need to generate a reference colour burst at the start of each frame, then output a sinusoid whose relative frequency to this reference burst indicated the colour. This is superimposed on the luminance signal to provide a composite output. With just the resistors all you'll get is levels of grey. Nial.Article: 124752
Dear All Summary: FPGA performs properly when configured by a BIT file but one function is performing incorrect when it is configured from the flash PROM, programmed with an MCS file generated from the good BIT file. Detailed: I am using a SPARTAN 3 (XC3S505PQ208C) with a (XCF02SVO20C) flash PROM in the ISE 7.1i environment. The circuit and my VHDL code was working properly until recently. I am sure nothing major changed but I am experiencing a problem which I cannot solve. I read 4 registers from the FPGA via an ISA bus interface into a PC. Three of these registers are hard coded and in the fourth register a bit is populated by a watchdog function implemented on the FPGA. The watchdog is serviced by writing to a register in the FPGA at a certain rate. When the watchdog is not timed out this bit is set to zero otherwise it is one I generate the BIT file for the FPGA and from it the MCS file for the PROM. After programming the PROM and cycling the power to configure the FPGA from the PROM the 3 hard coded register are read correctly but the watchdog bit in the fourth register indicates a watchdog time out (i.e. logic 1) even though the watchdog is reset and serviced properly. I assume that the configuration process is done properly since iMPACT indicates no problems except for the usual (WARNING:iMPACT:2257 - Startup Clock has been changed to 'JtagClk' in the bitstream stored in memory, but the original bit stream file remains unchanged) which I have seen since the first time I started using ISE. The other functions implemented on the FPGA works properly. This includes switching relays by writing to registers in the FPGA etc. I have changed between CCLK and JTAG Clock in [Generate Programming File >> Startup Options tab] with no success. I have also replaced the flash PROM. Without changing anything I configure the FPGA with the BIT file and the everything works properly. After reseting the watchdog timer and servicing it properly the bit in the register is read as 0 indicating that the watchdog happy. The other registers are read properly as in the case where the FPGA is configured from the PROM. What could be the problem? Partial configuration/ Wrong settings? What can i do to get rid of the warning messages mentioned above?Article: 124753
On 3 Okt., 12:08, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:1190990042.490029.3360@w3g2000hsg.googlegroups.com... > > > Hi > > > I am evaluating the possibility to use 2 resitor video output from > > FPGA similar to: > > >http://www.excamera.com/articles/15/ntsc.html > > > to generate color NTSC output, > > Antti, you'll only be able to generate a black and white signal > with this technique. > > For colour you need to generate a reference colour burst at the start > of each frame, then output a sinusoid whose relative frequency to this > reference burst indicated the colour. > > This is superimposed on the luminance signal to provide a composite > output. > > With just the resistors all you'll get is levels of grey. > > Nial. Nial dont be so sure ;) you can get NTSC color with 4 resistors for sure, and if you use very high clocked (500MHz) delta-sigma DAC you may get color NTSC with one resistor too I think. not very high quality but more than 8 colors should be possible. AnttiArticle: 124754
On Oct 3, 6:40 am, christ...@gmail.com wrote: > Dear All > > Summary: > FPGA performs properly when configured by a BIT file but one function > is performing incorrect when it is configured from the flash PROM, > programmed with an MCS file generated from the good BIT file. > > Detailed: > I am using a SPARTAN 3 (XC3S505PQ208C) with a (XCF02SVO20C) flash PROM > in the ISE 7.1i environment. The circuit and my VHDL code was working > properly until recently. I am sure nothing major changed but I am > experiencing a problem which I cannot solve. > > I read 4 registers from the FPGA via an ISA bus interface into a PC. > Three of these registers are hard coded and in the fourth register a > bit is populated by a watchdog function implemented on the FPGA. The > watchdog is serviced by writing to a register in the FPGA at a certain > rate. When the watchdog is not timed out this bit is set to zero > otherwise it is one > > I generate the BIT file for the FPGA and from it the MCS file for the > PROM. After programming the PROM and cycling the power to configure > the FPGA from the PROM the 3 hard coded register are read correctly > but the watchdog bit in the fourth register indicates a watchdog time > out (i.e. logic 1) even though the watchdog is reset and serviced > properly. I assume that the configuration process is done properly > since iMPACT indicates no problems except for the usual > (WARNING:iMPACT:2257 - Startup Clock has been changed to 'JtagClk' in > the bitstream stored in memory, but the original bit stream file > remains unchanged) which I have seen since the first time I started > using ISE. The other functions implemented on the FPGA works properly. > This includes switching relays by writing to registers in the FPGA > etc. I have changed between CCLK and JTAG Clock in [Generate > Programming File >> Startup Options tab] with no success. I have also > replaced the flash PROM. > > Without changing anything I configure the FPGA with the BIT file and > the everything works properly. After reseting the watchdog timer and > servicing it properly the bit in the register is read as 0 indicating > that the watchdog happy. The other registers are read properly as in > the case where the FPGA is configured from the PROM. > > What could be the problem? Partial configuration/ Wrong settings? > What can i do to get rid of the warning messages mentioned above? Partial configuration is unlikely. I would suggest looking at start-up issues. Does your design have some sort of global reset you can apply after configuration? Perhaps you could use this to see if the two configuration methods show similar results. Another possibility is the state of the surrounding circuitry at the time of configuration. Since you power cycle the FPGA when loading from PROM it's possible that some external logic is not in the same state as when you use IMPACT. Are you using the PlatformFlash serial flash for your system? If so you can try checking the "Load FPGA" button when you program the flash from iMPACT. This would still load the FPGA from the flash, but without power-cycling the system so you can see if this is a system start-up issue. HTH, GaborArticle: 124755
Hello, I started to learn tcl for support my design work. I try to use Xilinx' tools without GUI. I can't find method to config "Generate Programming File" bitgen tool in tcl shell. One way I find is manual editing *.ut file then: %exec bitgen -f pname.ut Is there the other way? Regards, Jerzy GburArticle: 124756
On Oct 2, 12:54 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > If the objective is to learn vhdl, all you need is > > 1. A simulator to verify and debug > the uut and testbench code and > > 2. Quartus or ise to view the rtl schematic. Yes, however, to someone who hasn't done it before, not taking the effort through to hardware leaves out part of the feeling of the experience. > If the objective is to toggle a few output pins, > then buy a board and run the demos. It just all makes more sense when you see the lights blinking. After you've done that, playing with the simulator is a very powerful, time saving tool. But sometimes "wasting" a few hours with real hardware is a precondition to being willing to work in simulation alone for weeks. IMHO, in terms of vendor sold/endorsed boards, Xilinx has the best hobbyist or self-funded-training offerings via Digilent. The plain spartan 3 kit is dated at this point but still easy to use, and inexpensive, still $100 as far as I know, though if buying another I'd get the biggest chip offered rather than the default. From news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk Wed Oct 03 07:44:03 2007 Path: newsdbm05.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!goblin1!goblin.stu.neva.ru!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!news.clara.net!wagner.news.clara.net!despina.uk.clara.net From: "Tom Lucas" <news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk> Newsgroups: comp.arch.embedded,comp.arch.fpga References: <1191335877.22751.0@proxy01.news.clara.net> <5mfbenFd8h6cU1@mid.individual.net> <1191420648.836140.188050@g4g2000hsf.googlegroups.com> Subject: Re: Basic VHDL Development kit Date: Wed, 3 Oct 2007 15:44:03 +0100 Lines: 41 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-RFC2646: Format=Flowed; Original X-Complaints-To: abuse@clara.net (please include full headers) X-Trace: 45d081086063155262707a6c6f1c20085768b55052fd6e1860649a004703aa49 NNTP-Posting-Date: Wed, 03 Oct 2007 15:42:17 +0100 Message-Id: <1191422537.39588.0@despina.uk.clara.net> Xref: prodigy.net comp.arch.embedded:260420 comp.arch.fpga:136721 <cs_posting@hotmail.com> wrote in message news:1191420648.836140.188050@g4g2000hsf.googlegroups.com... > On Oct 2, 12:54 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > >> If the objective is to learn vhdl, all you need is >> >> 1. A simulator to verify and debug >> the uut and testbench code and >> >> 2. Quartus or ise to view the rtl schematic. > > Yes, however, to someone who hasn't done it before, not taking the > effort through to hardware leaves out part of the feeling of the > experience. I'm inclined to agree. A project just isn't right without a good electric shock or a soldering iron burn :-) I started out in hardware design so I always prefer to play with bits and pieces where possible because simulators are a little joyless. >> If the objective is to toggle a few output pins, >> then buy a board and run the demos. > > It just all makes more sense when you see the lights blinking. After > you've done that, playing with the simulator is a very powerful, time > saving tool. But sometimes "wasting" a few hours with real hardware > is a precondition to being willing to work in simulation alone for > weeks. > > IMHO, in terms of vendor sold/endorsed boards, Xilinx has the best > hobbyist or self-funded-training offerings via Digilent. The plain > spartan 3 kit is dated at this point but still easy to use, and > inexpensive, still $100 as far as I know, though if buying another I'd > get the biggest chip offered rather than the default. I'll check those out, although the Probe 3 kit ratemonotonic suggested also looks to be pretty good. I've heard that Xilinx are the Microsoft of the FPGA world and behave similarly - I don't know if that is true though.Article: 124757
Hi Jerzy!
> I try to use Xilinx' tools without GUI. I can't find method to config
> "Generate Programming File" bitgen tool in tcl shell.
I'm not 100% sure what you're looking for, but you can set/configure the
"Generate Programming File" (and others) with TCL commands like the
following ones:
project set {Signature /User Code} {0831} -process {Generate Programming
File}
project set {Create Binary Configuration File} 1 -process {Generate
Programming File}
project set {Done (Output Events)} 5 -process {Generate Programming File}
XST is quite delicate about the name of an entry. I'd paste the commands
into the GUI's shell and check whether they have any effect in the dialogs.
Cheers
Arnim
Article: 124758Is there a way to detect if an error or warning occured during a simulation run in ModelSim scripting. I'm just trying something simple: what I'd like to do is have my test bench simulation set up script quit modelsim if there are no errors, or stop and leave modelsim running if an error occurs so I can look at the waveform trace (I'm launching modelsim automatically from Quartus). Any thoughts on what I should be looking at to see if an error occured? Thanks, ChrisArticle: 124759
On Oct 3, 10:59 am, Chris Maryan <kmar...@gmail.com> wrote: > Is there a way to detect if an error or warning occured during a > simulation run in ModelSim scripting. I'm just trying something > simple: what I'd like to do is have my test bench simulation set up > script quit modelsim if there are no errors, or stop and leave > modelsim running if an error occurs so I can look at the waveform > trace (I'm launching modelsim automatically from Quartus). > > Any thoughts on what I should be looking at to see if an error > occured? > > Thanks, > > Chris Not quite sure what your definition of 'error' is but if your testbench uses assertions to check that you're getting the proper results then the simulation will stop automatically for you for you to investigate waveforms. If no such assertions fire then the fact that the 'run -all' completes would mean there are no errors and Modelsim should end. Ex: assert (Mysignal = All_Things_Good) report "OOPS! Mysignal is not in the proper state" severity ERROR; You would have to set Modelsim to stop on severity level of 'ERROR' or higher. I believe this is the default, but in any case it is a settable thing (i.e. you can have it stop on severity 'WARNING' if you'd like). Not sure if this is what you're looking for or not though. KJArticle: 124760
Tom Lucas wrote:
> A project just isn't right without a good
> electric shock or a soldering iron burn :-) I started out in hardware
> design so I always prefer to play with bits and pieces where possible
> because simulators are a little joyless.
Simulation is good clean fun for me,
but if solder is your thing, have at it.
-- Mike Treseler
Article: 124761
Chris Maryan wrote:
> Is there a way to detect if an error or warning occured during a
> simulation run in ModelSim scripting. I'm just trying something
> simple: what I'd like to do is have my test bench simulation set up
> script quit modelsim if there are no errors, or stop and leave
> modelsim running if an error occurs so I can look at the waveform
> trace
You could run
vsim -c my_tb
from some script and return pass/fail.
If it passes, start quartus, else run
vsim my_tb -do my_tb.do
to run with waves for debug.
See the testbench here:
http://home.comcast.net/~mike_treseler/
for some command line examples.
(I'm launching modelsim automatically from Quartus).
That might be putting the cart
in front of the horse.
Unless the sim passes, I see no reason
to spend time running or
even starting up quartus.
-- Mike Treseler
Article: 124762Thanks for the input, but what I would like to do is not stop on an error (only on fatal, which is the default), catch all the errors and then script a decision based on whether errors had occured or not. That is, run -all completes regardless, reporting errors along the way, then if it completed without errors do something (quit modelsim), if it completed with errors do something else (don't quit). Chris On Oct 3, 1:15 pm, KJ <Kevin.Jenni...@Unisys.com> wrote: > On Oct 3, 10:59 am, Chris Maryan <kmar...@gmail.com> wrote: > > > Is there a way to detect if an error or warning occured during a > > simulation run in ModelSim scripting. I'm just trying something > > simple: what I'd like to do is have my test bench simulation set up > > script quit modelsim if there are no errors, or stop and leave > > modelsim running if an error occurs so I can look at the waveform > > trace (I'm launching modelsim automatically from Quartus). > > > Any thoughts on what I should be looking at to see if an error > > occured? > > > Thanks, > > > Chris > > Not quite sure what your definition of 'error' is but if your > testbench uses assertions to check that you're getting the proper > results then the simulation will stop automatically for you for you to > investigate waveforms. If no such assertions fire then the fact that > the 'run -all' completes would mean there are no errors and Modelsim > should end. > > Ex: > assert (Mysignal = All_Things_Good) > report "OOPS! Mysignal is not in the proper state" > severity ERROR; > > You would have to set Modelsim to stop on severity level of 'ERROR' or > higher. I believe this is the default, but in any case it is a > settable thing (i.e. you can have it stop on severity 'WARNING' if > you'd like). > > Not sure if this is what you're looking for or not though. > > KJArticle: 124763
On Oct 3, 1:37 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > Chris Maryan wrote: > > Is there a way to detect if an error or warning occured during a > > simulation run in ModelSim scripting. I'm just trying something > > simple: what I'd like to do is have my test bench simulation set up > > script quit modelsim if there are no errors, or stop and leave > > modelsim running if an error occurs so I can look at the waveform > > trace > > You could run > vsim -c my_tb > from some script and return pass/fail. > If it passes, start quartus, else run > vsim my_tb -do my_tb.do > to run with waves for debug. > See the testbench here: > http://home.comcast.net/~mike_treseler/ > for some command line examples. > > (I'm launching modelsim automatically from Quartus). > > That might be putting the cart > in front of the horse. > Unless the sim passes, I see no reason > to spend time running or > even starting up quartus. > > -- Mike Treseler Thanks Mike, running the sim twice as you suggested might be my answer, it doesn't take long. As for running Quartus first, I'm relying on it to give me gate level timings and pass that along to ModelSim. So my process is to compile in Quartus, then launch modelsim to test. If I was just doing RTL simulation, I could skip Quartus altogether. That and Quartus has a friendlier VHDL editor. ChrisArticle: 124764
On Oct 3, 10:44 am, "Tom Lucas" <news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk> wrote: > > Yes, however, to someone who hasn't done it before, not taking the > > effort through to hardware leaves out part of the feeling of the > > experience. > > I'm inclined to agree. A project just isn't right without a good > electric shock or a soldering iron burn :-) I started out in hardware > design so I always prefer to play with bits and pieces where possible > because simulators are a little joyless. Oh yes... the 75 cent radio control truck from the tag sale. Never did get it going, but learned to solder and launched an EE career. The burns healed fairly quickly... > I've heard that Xilinx are the Microsoft > of the FPGA world and behave similarly - I don't know if that is true > though. There might be an element to it, but the major difference is that Xilinx has to contend with Altera as first-rank competition, in a way that Microsoft at present doesn't. That keeps something of a lid on things, though not as much as one might wish for. You can control your degree of vendor lock in fairly easy - if you don't use their unique library functions, and use only the free download versions of the tools, and don't utilize any abuses of the language that one tool or the other might permit, then you should remain portable.Article: 124765
Chris Maryan wrote:
> Thanks Mike, running the sim twice as you suggested might be my
> answer, it doesn't take long.
> As for running Quartus first, I'm relying on it to give me gate level
> timings and pass that along to ModelSim.
Hmm. The quartus static timing is very good.
Why run a gate sim which is much slower
and tests less?
> So my process is to compile
> in Quartus, then launch modelsim to test.
> If I was just doing RTL
> simulation, I could skip Quartus altogether.
I spend most of my time in simulation,
but bring up quartus once in a while
to look at the RTL schematics.
-- Mike Treseler
Article: 124766cs_posting@hotmail.com wrote: > You can control your degree of vendor lock in fairly easy - if you > don't use their unique library functions, and use only the free > download versions of the tools, and don't utilize any abuses of the > language that one tool or the other might permit, then you should > remain portable. ...and far less efficient than you could be if you designed to the architecture. Now that doesn't necessarily mean instantiating primitives, but it does play into how you architect your design so that it makes best use of the target FPGA structure. Not doing this may lead to a design that is far larger and slower than one that is specifically designed to the architecture.Article: 124767
Thanks for the feedback. What you said brings up a more general question: what is your general design/validation process (in terms of switching between Quartus, ModelSim and whatever else)? In case it's not glaringly obvious, I'm relatively new to this. Chris On Oct 3, 2:18 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > Chris Maryan wrote: > > Thanks Mike, running the sim twice as you suggested might be my > > answer, it doesn't take long. > > As for running Quartus first, I'm relying on it to give me gate level > > timings and pass that along to ModelSim. > > Hmm. The quartus static timing is very good. > Why run a gate sim which is much slower > and tests less? > > > So my process is to compile > > in Quartus, then launch modelsim to test. > > If I was just doing RTL > > simulation, I could skip Quartus altogether. > > I spend most of my time in simulation, > but bring up quartus once in a while > to look at the RTL schematics. > > -- Mike TreselerArticle: 124768
Hi, I'm trying to test the golden PROM configuration on my XUP Virtex II Pro board. Trouble is that I'm not able to use the serial interface to carry out Built-In Self Tests. I'm using a serial-to-usb cable to connect the board's RS232 port to my USB port. I installed usb2serial drivers from Prolific. Now in hyperterminal I can see the BIST menu when I switch on the board, but it doesn't accept my input and doesn't proceed with the tests and doesn't produce any more output than the initial menu. I've set the baud rate and parity etc as said in the XUP manual. Do I have to configure anything else? because I've kept the default terminal emulation options in hyperterminal connection settings. RhishikeshArticle: 124769
On Oct 3, 2:25 pm, Ray Andraka <r...@andraka.com> wrote: > cs_post...@hotmail.com wrote: > > You can control your degree of vendor lock in fairly easy - if you > > don't use their unique library functions, and use only the free > > download versions of the tools, and don't utilize any abuses of the > > language that one tool or the other might permit, then you should > > remain portable. > > ...and far less efficient than you could be if you designed to the > architecture. Now that doesn't necessarily mean instantiating > primitives, but it does play into how you architect your design so that > it makes best use of the target FPGA structure. Not doing this may lead > to a design that is far larger and slower than one that is specifically > designed to the architecture. I thought we were talking about exploration and initial learning, not making products.Article: 124770
On Oct 3, 1:57 pm, Rhishi <rhi...@gmail.com> wrote: > Hi, > > I'm trying to test the golden PROM configuration on my XUP Virtex II > Pro board. Trouble is that I'm not able to use the serial interface to > carry out Built-In Self Tests. > > I'm using a serial-to-usb cable to connect the board's RS232 port to > my USB port. I installed usb2serial drivers from Prolific. Now in > hyperterminal I can see the BIST menu when I switch on the board, but > it doesn't accept my input and doesn't proceed with the tests and > doesn't produce any more output than the initial menu. > > I've set the baud rate and parity etc as said in the XUP manual. Do I > have to configure anything else? because I've kept the default > terminal emulation options in hyperterminal connection settings. > > Rhishikesh Your problem may be different, but... Test your "prolific" adapter before connecting it to the XUP. I went through at least a dozen of that brand before I found 4 that worked. (In other words, 75% were bad, brand new in the wrapper.) G.Article: 124771
Chris Maryan wrote:
> Thanks for the feedback. What you said brings up a more general
> question: what is your general design/validation process (in terms of
> switching between Quartus, ModelSim and whatever else)?
1. I follow an synchronous template for synthesis code.
This eliminates asynchronous feedback by design.
If there is more than one clock, I write
separate entities for each and use explicit
synchronization.
2. I run vcom from the editor to validate syntax
after a few lines of new code.
The editor jumps to the first syntax error.
3. As soon as some output ports are described
I generate a baseline reset/clock testbench
from the editor and validate initialization.
I add stimulus and verification procedures
to close the loop on the testbench with a
pass/fail output.
4. After each significant feature is described
and verified by simulation, I run synthesis
to check Fmax and the RTL viewer, and commit
the changes to svn source control.
-- Mike Treseler
Article: 124772On Oct 2, 6:01 pm, glen herrmannsfeldt wrote: > In the olden days (Apple II, IBM CGA) it was done with on/off switching > at four times the subcarrier frequency. That gives you 16 combinations > of phase and amplitude to choose from, which was good enough in those > days. Indeed, Woz's low-rez circuits were simply amazing. It wasn't obvious to me at first how he got different intensity levels. You have to notice that 1100 and 1000 have different DC levels... > If you allow for 128 times the subcarrier and allow for all on/off > combinations (that is, allow 128 bits per subcarrier cycle) you > should get a good number of hue/saturation/intensity combinations. It would be essentially a specialized delta-sigma DAC, but should be very interesting. You would have 128 hues, 64 saturations and 32 intensities (supposing 1 generates 1.5V and 0 is 0.5V, with the other resistor used to bring it to 0V for sync). You get less than 262,144 colors, however, since with 0 saturation the hue doesn't matter and with 0 intensity neither the hue nor the saturation matter. Here is a page I recommend to anyone interested in this kind of thing, by the way: http://www.rickard.gunee.com/projects/video/sx/howto.php -- JecelArticle: 124773
On Oct 3, 7:49 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > Chris Maryan wrote: > > Thanks for the feedback. What you said brings up a more general > > question: what is your general design/validation process (in terms of > > switching between Quartus, ModelSim and whatever else)? > > 1. I follow an synchronous template for synthesis code. > This eliminates asynchronous feedback by design. > If there is more than one clock, I write > separate entities for each and use explicit > synchronization. > > 2. I run vcom from the editor to validate syntax > after a few lines of new code. > The editor jumps to the first syntax error. > > 3. As soon as some output ports are described > I generate a baseline reset/clock testbench > from the editor and validate initialization. > I add stimulus and verification procedures > to close the loop on the testbench with a > pass/fail output. > > 4. After each significant feature is described > and verified by simulation, I run synthesis > to check Fmax and the RTL viewer, and commit > the changes to svn source control. > > -- Mike Treseler Thanks Mike, insightful and useful. ChrisArticle: 124774
cs_posting@hotmail.com wrote:
> You can control your degree of vendor lock in fairly easy - if you
> don't use their unique library functions, and use only the free
> download versions of the tools, and don't utilize any abuses of the
> language that one tool or the other might permit, then you should
> remain portable.
I mostly agree.
Every design has different constraints.
In my experience, reuse, straightforward
simulation and clean code has been more valuable
than maximum Fmax and minimum LUTs.
But I understand that there are others designing
on the edge that have to sacrifice some reuse
for performance or utilization.
-- Mike Treseler
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