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 grab it here (no registration required) http://groups.google.com/group/antti-brain/files?hl=en This time a little non FPGA stuff also included, Audio Processing and well see this!! a PIC microcontroller too! (I am much more AVR fun) ok, i cheated a little the PIC is actually inside an FPGA (of course) it does do encode RDS signal that i tried to analyze, well unfortunatly my HD audio card does have 48khz hard filter when using 192KHz sampling rate, but still it was fun to see the RDS signal coming out and into my PC. Hm.. but after looking at PIC because they are used in most RDS projects i did happen to look the "new" PIC's that i never have bothered to check out. some are pretty funny, the dsPIC in DIP18 package, cheap fast engine. hm.. beats AVRs on MIPS burned for sure. AnttiArticle: 142276
On Jul 31, 4:56=A0pm, Griffin <captain.grif...@gmail.com> wrote: > On Jul 30, 1:44=A0pm, Frank Buss <f...@frank-buss.de> wrote: > > > Griffin wrote: > > > The thing is is that I need to readout the value of the counter every > > > (say) microsecond or less, which is why I figured I would need a RAM > > > buffer, the idea being I would fill the ram with the counter values > > > then read it all out to the computer in one flash, then we restart th= e > > > process with (ideally) as little dead time in between "runs". > > > First you should think about your problem in more detail, like how fast > > your counters can be triggered, how fast you need to read it and for wh= ich > > time, all with hard numbers. Then you can plan better what you need. > > Will do. > > > > I was planning on using the Microblaze synthesized CPU, which I > > > understand is the Xilinx provided system. > > > If you needethernetfor the speed, this would be a good idea, because > > developing it on your own, or even trying to use some ethernet core fro= m > > OpenCores, is not a good idea for a beginner. Caching in external RAM a= nd > > transfering with RS232 would be easier with a CPU, too. > > Your help is very much appreciated. > > The trick here is is that I'm not sure how to implement and actually > use IPs with a synthesized CPU, which is what I must look into I > guess. Essentially, I understand the project build process until one > gets to the Xilinx SDK. The way I understand it, the SDK allows one to > apply C and C++ code to an FPGA project. Yes, SDK allows to load the C/C++ code to microblaze that is configured in FPGA. Now, this microblaze (or any other soft-core processor) is on of the hardwares that can be in FPGA. You can describe your own peripherals/ hardwares using languages like VHDL/ Verilog (or other..) or use IPs designed by others. These can also be placed within the same FPGA. Now, I think which is your question: How to integrate both hardware and software. Use (assuming you want to use microblaze) Xilinx's EDK or XPS . You can use "The Create and Import Peripheral Wizard" in XPS to add your IPs into the system and make it talk with the microblaze. > > Can anyone point me in the right direction for use of the SDK to > implement IPs such as memory interfaces and ethernet controllers (i.e. > a good reference document, a working example of something doing one of > these things, etc.) You can get some, just google with keywords like: custom peripheral edk; create and import peripheral wizard; ... > > Thanks in advance! > > SeanArticle: 142277
On Fri, 31 Jul 2009 12:53:02 +0200, Charles Gardiner <invalid@invalid.invalid> wrote: >Hi Mike, > >in case your problem is still an issue... > >I am just writing up a product spec for a customer and your issue came >to mind: > >Do you have XRES connect to ground through a 10 KOhm resistor? There is >a description to this pin on page 2-32 (and a few other distributed >places) in the current EC/ECP handbook. > >Regards, >Charles I have subsequently established that it is definitely a bug in ISPLever 7.2 SP1 and SP2, but only the starter version. I'm in the process of getting some sample projects that illustrate the problem to Lattice. Re. XRES - in the process of debugging 25 hand-built PCBs, I did find that lack of XRES will prevent JTAG downlaods working.Article: 142278
Some food fo thought:
I'm working on a new design in which I need to bring 64 LVDS (250Mbps
each/ 125MHz fmax) lines into a Spartan3 FPGA. The distance between
the source and the FPGA is less than 2" / 5cm. Ofcourse there is a
solid ground plane underneath the signals (the board will have at
least 4 layers).
I'm wondering if I can save a lot of pins if I feed the LVDS signals
single ended into the FPGA (terminate the pair close to the FPGA and
leave one end dangling). I could bias the Vref pins on the FPGA to the
centre point of the LVDS signal. If I set the input pin type to GTL it
should work on paper. The LVDS signal has enough swing to exceed the
minimum signal amplitude.
Anyone ever tried this?
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142279On 1 Aug., 19:27, n...@puntnl.niks (Nico Coesel) wrote: > I'm wondering if I can save a lot of pins if I feed the LVDS signals > single ended into the FPGA (terminate the pair close to the FPGA and > leave one end dangling). I could bias the Vref pins on the FPGA to the > centre point of the LVDS signal. If I set the input pin type to GTL it > should work on paper. The LVDS signal has enough swing to exceed the > minimum signal amplitude. You have no guarantee on the common mode voltage so this is a risky approach. But there is no reason for that. Just use one of the existing single ended high speed low swing signaling standards. (HSTL, SSTL, whatever) Also, you should use internal termination. Kolja Sulimma www.cronologic.deArticle: 142280
On Jul 31, 8:07=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Jul 31, 11:42=A0am, Andy <jonesa...@comcast.net> wrote: > > > Couldn't you use an unconstrained vector port? > > Not when you don't have control of the design that you're interfacing > with that you also don't happen to want to connect up all the I/O to. > The specific example that I gave earlier in the thread is... > > "When designing a board, it certainly is the case where you can > legally have unconnected pins and those pins might happen to be bits > of some 'bus' of related pins. =A0Back in 2005, I had a device which > happened to have a 24 bit data bus of which I was only using 16 bits > and the part had no requirement to drive unused pins on that bus." > > Since the VHDL file for the netlist for the PCBA is written by the > schematic capture ECAD tool, I don't have direct control of that VHDL > file other than to modify something on the schematic for the board. > One work around would be to make one pin nets for each of the pins > that are 'unused'. =A0Now the ECAD tool will write out a netlist with > everything attached...the downside here is that when doing board > design, 'one pin nets' are usually a form of design error. > Intentionally adding noise to this check by creating one pin nets just > to satisfy a simulation tool is counter-productive. =A0There are other > work arounds, with their own particular disadvantages as well. > > One could also be further removed from the PCBA design in that maybe > you don't have design control of the PCBA, you're simply the recipient > of the design in which case the work around is manual edits to the > VHDL netlist for the board. > > > And it does not help with record types. > > Record types don't need any help, they can be defaulted by the usual > method of supplying an initializer on the entity. =A0The problem is with > vectors (of any type). > > > And if you did allow open portions of vectored port associations (in > > some past/future version) would that work with unconstrained ports? > > Maybe that's where it ran afoul in the first place. > > Maybe...but in the process of making this change they created a > situation where a common hardware design situation (i.e. unconnected > pins on a chip) can not be modelled. =A0Sometimes some may forget that > the 'H' in VHDL stands for hardware. > > Kevin Jennings Very good points, thanks. I was thinking of entities for custom stuff that I wrote. There's usually other hacking involved anytime I've tried to use a VHDL netlist of a board for anything. Would it be legal to associate (others =3D> 'Z') to those portions of the port, instead of OPEN? It's been a while since I had to do something like that. Preference for resolved signals with tri-state values came about in '93 I believe. IINM, it was at that time that guarded blocks and disconnects were deprecated(?). Maybe the OPEN binding was abandoned in favor of tri-state literals? AndyArticle: 142281
"Nico Coesel" <nico@puntnl.niks> wrote in message news:4a7477d0.351422078@news.planet.nl... > Some food fo thought: > > I'm working on a new design in which I need to bring 64 LVDS (250Mbps > each/ 125MHz fmax) lines into a Spartan3 FPGA. The distance between > the source and the FPGA is less than 2" / 5cm. Ofcourse there is a > solid ground plane underneath the signals (the board will have at > least 4 layers). > > I'm wondering if I can save a lot of pins if I feed the LVDS signals > single ended into the FPGA (terminate the pair close to the FPGA and > leave one end dangling). I could bias the Vref pins on the FPGA to the > centre point of the LVDS signal. If I set the input pin type to GTL it > should work on paper. The LVDS signal has enough swing to exceed the > minimum signal amplitude. > > Anyone ever tried this? > > -- The thing that would concern me is how to guarantee that VREF is held at the centerpoint (common mode) of the signal swing. If you were only dealing with one pair then you get tricky and extract the common-mode point from that pair - assuming that the signal was always transitioning. Knowing that you've selected the proper sampling point for all 64 signal will take a leap of faith because I don't think that the common-mode points are guaranteed that accurately. LVDS does take a lot of pins, but its advantages (low power, low SSO footprint, simple termination scheme), in my experience, have always outweighed the I/O count requirements. Bob -- == All google group posts are automatically deleted due to spam ==Article: 142282
"BobW" <nimby_GIMME_SOME_SPAM@roadrunner.com> wrote:
>
>"Nico Coesel" <nico@puntnl.niks> wrote in message
>news:4a7477d0.351422078@news.planet.nl...
>> Some food fo thought:
>>
>> I'm working on a new design in which I need to bring 64 LVDS (250Mbps
>> each/ 125MHz fmax) lines into a Spartan3 FPGA. The distance between
>> the source and the FPGA is less than 2" / 5cm. Ofcourse there is a
>> solid ground plane underneath the signals (the board will have at
>> least 4 layers).
>>
>> I'm wondering if I can save a lot of pins if I feed the LVDS signals
>> single ended into the FPGA (terminate the pair close to the FPGA and
>> leave one end dangling). I could bias the Vref pins on the FPGA to the
>> centre point of the LVDS signal. If I set the input pin type to GTL it
>> should work on paper. The LVDS signal has enough swing to exceed the
>> minimum signal amplitude.
>>
>> Anyone ever tried this?
>>
>> --
>
>The thing that would concern me is how to guarantee that VREF is held at the
>centerpoint (common mode) of the signal swing. If you were only dealing with
The datasheet of the source chip specifies that. I more or less assume
the source chip has the same centerpoint on all outputs.
>one pair then you get tricky and extract the common-mode point from that
>pair - assuming that the signal was always transitioning. Knowing that
IMHO you don't need a signal that is always toggling. If you connect a
resistor to each leg of the pair and a capacitor to ground (resistor
divider between the two legs) then the voltage across the capacitor
should be the centre voltage no matter what the LVDS signal looks
like.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142283"Nico Coesel" <nico@puntnl.niks> wrote in message news:4a749265.358227234@news.planet.nl... > "BobW" <nimby_GIMME_SOME_SPAM@roadrunner.com> wrote: > >> >>"Nico Coesel" <nico@puntnl.niks> wrote in message >>news:4a7477d0.351422078@news.planet.nl... >>> Some food fo thought: >>> >>> I'm working on a new design in which I need to bring 64 LVDS (250Mbps >>> each/ 125MHz fmax) lines into a Spartan3 FPGA. The distance between >>> the source and the FPGA is less than 2" / 5cm. Ofcourse there is a >>> solid ground plane underneath the signals (the board will have at >>> least 4 layers). >>> >>> I'm wondering if I can save a lot of pins if I feed the LVDS signals >>> single ended into the FPGA (terminate the pair close to the FPGA and >>> leave one end dangling). I could bias the Vref pins on the FPGA to the >>> centre point of the LVDS signal. If I set the input pin type to GTL it >>> should work on paper. The LVDS signal has enough swing to exceed the >>> minimum signal amplitude. >>> >>> Anyone ever tried this? >>> >>> -- >> >>The thing that would concern me is how to guarantee that VREF is held at >>the >>centerpoint (common mode) of the signal swing. If you were only dealing >>with > > The datasheet of the source chip specifies that. I more or less assume > the source chip has the same centerpoint on all outputs. > >>one pair then you get tricky and extract the common-mode point from that >>pair - assuming that the signal was always transitioning. Knowing that > > IMHO you don't need a signal that is always toggling. If you connect a > resistor to each leg of the pair and a capacitor to ground (resistor > divider between the two legs) then the voltage across the capacitor > should be the centre voltage no matter what the LVDS signal looks > like. Ahhh, yes. Silly me. I hope this works out for you. I suspect it will if you adapt VREF to the true centerpoint of one of the signals and if all the driver's common mode points stay fairly close to each other. If one of those pairs is a forwarded clock, and if you decide to do the VREF adapt technique, then I wouldn't use the clock line for that function. LVDS is not intrinsically source terminated (it's high impedance drive [current source]). So, if you get any type of end reflection it will eventually come back toward that receiver. Data lines are somewhat forgiving. Clock lines are like women. Bob -- == All google group posts are automatically deleted due to spam ==Article: 142284
Hi, I am testing a simple SPI core, I would like to check it against a lcd module and a touch screen controller. I did simple scripts to exercise the spi, but I would like to check more stuff, like timing (maximum scl clock allowed by the display, minimum set up time of various signals and so on), random sending of chars and report a fail/pass. I don't know how to check how much time is during a output signal for example. Is there a simple tutorial on how to implement these checks and organize them into webise, run them all automatically? All the stuff I found was very helpful to implement simple checking of desired results, but I have found almost anything about timing checks. Is there any opensource collection of protocol verificators, stuff that I could include in my project and could tell me I am having any violation on protocols I am using? TIA, Giuseppe MarulloArticle: 142285
On Wed, 29 Jul 2009 11:09:17 -0700, "Pete Fraser" <pfraser@covad.net> wrote: >"Philip Pemberton" <usenet09@philpem.me.uk> wrote in message=20 >news:00b7c995$0$4795$c3e8da3@news.astraweb.com... > >> Signetics were definitely before MMI. > >Yes. I remember marking up fuse maps by hand, >then sending them away to Signetics and waiting >for a couple of days to get the parts back. > >After a few weeks we got an upgrade to our >programmer that allowed us to program without >trashing too many parts (as long as we blasted them >with freeze spray during programming). > >Pete=20 > I remember hearing of that second and third hand. Nice to hear someone actually there.Article: 142286
Hi, Ive got a design that uses the spartan XC3S500E, but when I populate the design with the smaller, but compatible XC3S250E and generate a bit stream to suit, it fails to program the SPI flash. With a .BIIT and a .MCS (which works correctly when you download it direct to the XC3S250E FPGA), it fails to program the external M25P80 SPI flash using iMPACT 10.1 and a Platform Cable USB II jtag adaptor. The error message I get with two different identical boards, is a failure at address 0 (board A) and failure at address 1024 (board B) I have repalced the flash memories on both boards as a sanity check, but as expected, no dice. The very same design works perfectly with 4 other boards, identical, except populated with the 500E. Anyone have any idea's on what I could be doing wrong? many thanks, steve IMPACT 10.1 message window dump PROGRESS_START - Starting Operation. Identifying chain contents ....'1': : Manufacturer's ID =Xilinx xc3s250e, Version : 1 INFO:iMPACT:1777 - Reading C:/Xilinx/10.1/ISE/spartan3e/data/xc3s250e.bsd... INFO:iMPACT:501 - '1': Added Device xc3s250e successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- done. PROGRESS_END - End Operation. Elapsed time = 1 sec. // *** BATCH CMD : identifyMPM // *** BATCH CMD : assignFile -p 1 -file "C:/250test.bit" '1': Loading file 'C:/250test.bit' ... done. INFO:iMPACT:501 - '1': Added Device xc3s250e successfully. ---------------------------------------------------------------------- ---------------------------------------------------------------------- Selected part: M25P80 // *** BATCH CMD : attachflash -position 1 -spi "M25P80" // *** BATCH CMD : assignfiletoattachedflash -position 1 -file "C:/ 250etest.mcs" // *** BATCH CMD : attachflash -position 1 -spi "M25P80" // *** BATCH CMD : Program -p 1 -spionly -e -v Maximum TCK operating frequency for this device chain: 10000000. Validating chain... Boundary-scan chain validated successfully. '1': SPI access core not detected. SPI access core will be downloaded to the device to enable operations. INFO:iMPACT - Downloading core file C:/Xilinx/10.1/ISE/spartan3e/data/ xc3s250e_spi.cor. PROGRESS_START - Starting Operation. '1': Downloading core... done. '1': Reading status register contents... INFO:iMPACT:2219 - Status register values: INFO:iMPACT - 0011 0111 1001 1000 0000 0000 0000 0000 INFO:iMPACT:2492 - '1': Completed downloading core to device. INFO:iMPACT - '1': Checking done pin....done. '1': Core downloaded successfully. '1': IDCODE is '13' (in hex). '1': ID Check passed. '1': IDCODE is '13' (in hex). '1': ID Check passed. '1': Erasing Device. '1': Programming Flash. '1': Reading device contents... Failed at address, 1024 '1': Verification Terminated PROGRESS_END - End Operation. Elapsed time = 19 sec.Article: 142287
Steve <srkh28@gmail.com> wrote:
>Hi,
>Ive got a design that uses the spartan XC3S500E, but when I populate
>the design with the smaller, but compatible XC3S250E and generate a
>bit stream to suit, it fails to program the SPI flash. With a .BIIT
>and a .MCS (which works correctly when you download it direct to the
>XC3S250E FPGA), it fails to program the external M25P80 SPI flash
>using iMPACT 10.1 and a Platform Cable USB II jtag adaptor.
>
>The error message I get with two different identical boards, is a
>failure at address 0 (board A) and failure at address 1024 (board B)
>I have repalced the flash memories on both boards as a sanity check,
>but as expected, no dice.
>
>The very same design works perfectly with 4 other boards, identical,
>except populated with the 500E.
>
>Anyone have any idea's on what I could be doing wrong?
Maybe the loading of the JTAG bus is different. Try to put a 22pf
capacitor on the JTAG clock line to slow it down a little. Otherwise
get a logic analyzer to see what the JTAG bus is doing.
I've had similar problems with the parallel Xilinx cable. It turned
out they steer tck, tms and tdo at the same time which is a bad idea
because it makes the timing extremely critical.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142288You may want to consider learning System Verilog. This has greater functonality than Verilog for testbench generation. There is also an open standard called OVM which includes a lot of the things you need when designing a testbench. However it all depends how far you want to go as learning this would require quite a few hours of study. If you are prepared to put the effort in you could do the things you want in Verilog. Cheers JonArticle: 142289
On Sun, 02 Aug 2009 00:58:23 +0200, Giuseppe Marullo wrote:
>I am testing a simple SPI core, I would like to check it against a lcd
>module and a touch screen controller.
>
>I did simple scripts to exercise the spi, but I would like to check more
>stuff, like timing (maximum scl clock allowed by the display, minimum
>set up time of various signals and so on), random sending of chars and
>report a fail/pass.
>
>I don't know how to check how much time is during a output signal for
>example.
That one is quite easy.
In your testbench...
initial begin : signal_width_tester
time start_time, pulse_width;
@(posedge my_signal) start_time = $time;
@(negedge my_signal) pulse_width = $time = start_time;
$display("my_signal was high for %t", pulse_width);
end
Using the %t formatter gives pretty output for time values,
provided you did the right things with $timeformat somewhere in
the testbench:
initial $timeformat(-9,0,"ns",0); // print times in whole ns
If you don't want to see the pulse width printed for every
pulse, you may prefer to use Verilog's built-in timing checks.
These require you to use the specify-block construct. You
can add them to the testbench:
module testbench;
// ... signals needed for TB
wire my_signal; // we will check this one
// ... other TB stuff - clock generator, DUT etc.
specify // this is where we do the checks
specparam minimum_width = 5;
$width((posedge my_signal), minimum_width);
endspecify
endmodule
This will automatically check every pulse on "my_signal" and
throw an error if the rise-to-fall pulse width is less than
the minimum you specified.
>Is there a simple tutorial on how to implement these checks and organize
>them into webise, run them all automatically?
Nothing that I know of, sorry. As far as running the checks
automatically is concerned, the easiest way is just to write
a piece of procedural Verilog code that performs each test
in turn. That's easier if you write each test as a Verilog
task.
Any good Verilog reference guide or textbook should list
all the built-in timing checks, and the system functions
such as $time and $timeformat.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 142290
On Sun, 02 Aug 2009 11:04:48 +0100, Jonathan Bromley wrote:
> initial begin : signal_width_tester
> time start_time, pulse_width;
> @(posedge my_signal) start_time = $time;
> @(negedge my_signal) pulse_width = $time = start_time;
oops, sorry, that should be (obviously!)
@(negedge my_signal) pulse_width = $time - start_time;
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 142291Hi Noel, > > Maybe the loading of the JTAG bus is different. --> This method of programming does not use the JTAG interface as such. A small block of code is first doenload into the FPGA that builds a SPI type bridge to the SPI flash. Then, and image is sent via JTAG and should be written to the SPI flash. JTAG works fine, as downloading the image to the FPGA works correct, and the very smae circuit works fine with the 500E. Try to put a 22pf > capacitor on the JTAG clock line to slow it down a little. --> Id be inclined to avoid this - the device is 75MHz. The entire set up works fine for the 500E, but not the 250E. steveArticle: 142292
On Sun, 02 Aug 2009 11:04:48 +0100, Jonathan Bromley wrote:
> module testbench;
> // ... signals needed for TB
> wire my_signal; // we will check this one
> // ... other TB stuff - clock generator, DUT etc.
>
> specify // this is where we do the checks
> specparam minimum_width = 5;
> $width((posedge my_signal), minimum_width);
> endspecify
>
> endmodule
Oh dear, I seem to be very accident-prone today.
This won't work, for two reasons:
(1)
The parentheses around "posedge my_signal"
should not be there. This is correct:
$width(posedge my_signal, minimum_width);
(2)
Timing checks, and everything else in specify
blocks, work only on ports of a module, not internal
signals. So the easiest way to build a checker is
to package it as a module...
module pulse_width_checker(input my_signal);
specify ....... endspecify
endmodule
And then connect an instance of that module to
the signal you want to check.
In practice it's obviously a good idea to build
a module that does a complete set of checks on,
for example, your SPI bus.
Apologies for the various stupidities.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 142293Hi can anyone tell me what is the range of price of mentor "questa" simulator. I was unable to find it. if anyone knows please tell me. thank you ZoranArticle: 142294
Zorjak wrote:
> can anyone tell me what is the range of price of mentor "questa"
> simulator. I was unable to find it. if anyone knows please tell me.
About the price of a small new car.
-- Mike Treseler
Article: 142295
Steve <srkh28@gmail.com> wrote:
>
>Hi Noel,
>
>>
>> Maybe the loading of the JTAG bus is different.
>
>--> This method of programming does not use the JTAG interface as
>such. A small block of code is first doenload into the FPGA that
>builds a SPI type bridge to the SPI flash. Then, and image is sent via
>JTAG and should be written to the SPI flash. JTAG works fine, as
>downloading the image to the FPGA works correct, and the very smae
>circuit works fine with the 500E.
>
>Try to put a 22pf
>> capacitor on the JTAG clock line to slow it down a little.
>
>--> Id be inclined to avoid this - the device is 75MHz.
>
>The entire set up works fine for the 500E, but not the 250E.
I still think this may be a timing problem somewhere. How are the
timing constraints on the SPI interface? Are the flipflops inside the
IOBs?
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142296Mike Treseler schrieb: > Zorjak wrote: > >> can anyone tell me what is the range of price of mentor "questa" >> simulator. I was unable to find it. if anyone knows please tell me. > > About the price of a small new car. > > -- Mike Treseler Hi Mike, that must have been a special offer! The price I got three/four years ago was the equivalent of a relatively well equiped medium size new car. I chose Aldec (Riviera) instead with most of the bits-n-bobs activated and am perfectly satisfied with the tool. Not exactly cheap either though. About the price of a smallish new car... ;) CharlesArticle: 142297
> In practice it's obviously a good idea to build > a module that does a complete set of checks on, > for example, your SPI bus. > > Apologies for the various stupidities. Wow, thanks Jonathan for the detailed info, I will try to build something tomorrow.Article: 142298
maxascent wrote: > You may want to consider learning System Verilog. This has greater > functonality than Verilog for testbench generation. There is also an open > standard called OVM which includes a lot of the things you need when > designing a testbench. However it all depends how far you want to go as > learning this would require quite a few hours of study. If you are prepared > to put the effort in you could do the things you want in Verilog. > > Cheers > > Jon I will take a look at it thanks, but I am still learning Verilog... BTW, how does system verilog does integrate with webise? GiuseppeArticle: 142299
Steve wrote: > > Ive got a design that uses the spartan XC3S500E, but when I populate > the design with the smaller, but compatible XC3S250E and generate a > bit stream to suit, it fails to program the SPI flash. > <snip> > Anyone have any idea's on what I could be doing wrong? > some things to check: - Set the FPGA mode pins to JTAG mode, not to SPI mode, when programming over JTAG using the Impact SPI flash core. ( Otherwise the FPGA SPI boot process can fight with the JTAG port ) - Change the JTAG clock rate used by Impact to one of the slower speeds, and make sure it can reliably run the JTAG loopback test at that rate Brian
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