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 29 Apr 2002 08:03:18 -0700, ospyng@yahoo.com (spyng) wrote: >hi, >does anyone have experience these? > >CLK pad input to FF show up as unconstraint path during timing >analysis. and reduce coverage of timing constraint (90.5%). These >un-constraint paths are the clock delay from the clk pad to the clk >pin of the FFS > >Clk Pad input goes through a DCM and generate a internal clk to most >of the ffs in the design. there is currently a period constraint on >the clk pad input and during translate, there is message that show >that the period constraint have been push through the DCM and new >period constraint had been generated for the internal clock. The >internal clock period constraint is working fine. > >Why are all paths from Clk pad input to all ffs clk pin show up as an >unconstraint path? Because they're not constrained. The delay from the input pin to an internal flip-flop or RAM has no effect on the speed at which the device can be clocked internally. If you have a 50 MHz period constraint, the internal paths do not care if the delay from the clock pin to the internal FFs and RAMs is 0.5ns or 500ns, as long as that delay is common to all devices; in either case, you'll still be able to run at 50 MHz. (Of course, there is the issue of whether a 500ns path could actually pass a 10ns pulse, but that's a topic for another day.) I always add constraints for the pads-to-internal-devices clock paths, because I don't want my unconstrained paths report to be cluttered with stuff that's actually OK. And it's also a good way to confirm that the delay is what I expect it to be. For example, I added the following constraint in the ucf file to a 100 MHz clock passing through a DCM in a 2V3000: TIMESPEC TSCLK04 = FROM PADS(ext_clk100) TO FFS : 0.5; Bob Perlman ----- Cambrian Design Works http://www.cambriandesign.comArticle: 42626
In article <3cccf815@news.broadpark.no>, Stein Kjølstad <stein.kjolstad@visitech.no> wrote: >Is it possible to use the dedicated SelectMap data pins D0..D7 as ordinary >IO-pins >when configuration is finsihed and at the same time support partial >reconfiguration? Readback does not need to be supported. I would like D0..D7 >to be used as part of a 16 bit wide microprocessor data bus, when the FPGA >is not in configuration mode or partial reconfiguration mode. I assume you are refering to Virtex 1 family (Virtex/Virtex E/Spartan II and IIe) and not the Virtex 2? This pertains to Virtex 1: In order to enable partial reconfiguration, those pins must be used as the dedicated SelectMap port, so you can't share the pins if you want to do partial reconfiguration on the same design, to the best of my recolection. Also, if you want to do partial reconfiguration from WITHIN the part, you have to have another set of pins to drive the SelectMap port. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 42627
Peter Alfke wrote: > > Click on > http://www.xilinx.com/partinfo/ds006.pdf > > and look for the XC4000E/XL pin-out tables. > You may have to print out two pages and do a visual compare... > Sorry for the inconvenience, but my memory does not serve me well > enough to give you a reliable answer. Well, I did the heavy lifting and it appears that the two chips are pin compatible - or at least I could drop in the 4010 for my application. Still, I'd sleep better knowing that someone else had already done this with no problems. JonArticle: 42628
Jon, if you "did the heavy lifting"(=comparing two sets of 144 names), and found that the pin descriptions are identical for the two parts, then you have no reason to hesitate. We made these devices intentionally pin-compatible. We used to make a big issue of this, allowing migration to a larger device, or allowing prototyping with a larger chip, then streamlining the design for production in a smaller chip, all without changing the pc-board. Just go ahead and trust us... Peter Alfke, Xilinx Applications ================================ Jon wrote: > Peter Alfke wrote: > > > > Click on > > http://www.xilinx.com/partinfo/ds006.pdf > > > > and look for the XC4000E/XL pin-out tables. > > You may have to print out two pages and do a visual compare... > > Sorry for the inconvenience, but my memory does not serve me well > > enough to give you a reliable answer. > > Well, I did the heavy lifting and it appears that the two chips are pin > compatible - or at least I could drop in the 4010 for my application. > Still, I'd sleep better knowing that someone else had already done this > with no problems. > > JonArticle: 42629
"Frank Zampa" <NOSPAMingzampa77@yahoo.com> schrieb im Newsbeitrag news:3ccce74e.1754152@news.inet.it... > Hi, I must configure some pins on this device with 24mA output > drive.Where can I find this option (in the UCF file, in the Project > Manager, ..)? In the UCF write NET my_net_name drive=24; -- MfG FalkArticle: 42630
Patrik Eriksson <patrik.eriksson@netinsight.net> wrote in message news:<3CC51356.90000@netinsight.net>...
> My question was/is:
>
> I'm using an DCM to deskew an external clock relative to an internal
> clock. The feedback signal is connected through an global clock input
> pad. How does the input delay of the feedback signal affect the skew
> between the internal and external clock?
>
> Device: xc2v1500-4FG676C
>
> Xilinx support answered the following:
>
> The return delay to the DLL must be equal to the dealy to the other chip.
> If the delay is not the same then the external clock will not appear to
> be deskew.
>
> The delay that the input buffers introduce must be monitored as well.
>
> In a board-level clock deskew; when two different I/O Standard IBUFGs
> for the CLKIN and the CLKFB, the DCM will not lock.
>
> This happens because the maximum phase difference allowed for the DCM to
> work correctly between CLKIN and CLKFB is 100 ps. If the CLKFB and CLKIN
> are using two different I/O standards that introduce a differential
> delay greater than 100 ps, the CLKDLL will not lock or function correctly.
>
> One example is using an IBUFG_LVPECL for the CLKIN and IBUFG for the
> CLKFB. The differential delay in this case is 150 ps; therefore, the DCM
> will not work.
>
> To prevent this, ensure that the maximum phase difference between CLKFB
> and CLKIN is less than 100 ps.
>
>
> Can anyone help me understand the answer? If the phase difference
> between CLKFB and CLKIN is less than 100 ps I don't need to deskew the
> signals ;-()
Howdy Patrik,
I'm surprised by several things:
1. That no-one (including Xilinx) has responded to this post
2. That Xilinx would misunderstand your question so much
3. That Xilinx would give you that answer (even if they did
misunderstand your question).
As much as I hate to say it, I think you have ignore Xilinx's answer
here.
CLKIN_CLKFB_PHASE (the value quoted above by Xilinx) appears to be an
output timing parameter, not input (this it the reason for my
statement #3, above). Do a search in the .pdf.
I can guess an answer for you (it's the same thing that I've assumed
in my use of offchip deskew on the Virtex-E), but you may want to
repose your question to Xilinx, or maybe someone else that knows for
sure will respond here.
My assumption when generating a deskewed clock is that you must count
everything. You have to count the on-chip routing delay from the
DLL/DCM, count the output IOB delay driving off chip, count the
routing delay on the PCB, and count the input IOB delay back on chip.
The best (only?) way to get ALL of these values, that I'm aware of, is
to run timing analyzer.
But in looking at this a bit closer, I realized that I have a question
about this as well. Not that it will change my design - on the PCB, I
simply make the feedback net the same length as the net going to the
remote device, and that gets me close enough.
My question arises from the output of timing analyzer, with respect to
using a normal `GCLK' pin vs. a `DLL' pin for the clock input to a
DLL:
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tiodll 0.000 CLKIN1
CLKIN1_ibuf
net (fanout=1) 0.000 CLKIN1_c
Tdllino -1.924 I14/I24/I0
net (fanout=1) 0.000 I14/clk1_dll
Tgio 0.500 I14/I23/I0
net (fanout=373) 0.729 clk1
---------------------------- ------------------------------
Total -0.695ns (-1.424ns logic, 0.729ns route)
But that can't be right, can it?! Tiodll is really zero? Compare
that to when you use a global clock input:
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tgpio 0.700 CLKIN2
CLKIN2_ibuf
net (fanout=1) 0.000 CLKIN2_c
Tdllino -1.924 I14/I15/I0
net (fanout=1) 0.000 I14/clk2_dll
Tgio 0.500 I14/I18/I0
net (fanout=2371) 0.829 clk2
---------------------------- ------------------------------
Total 0.105ns (-0.724ns logic, 0.829ns route)
Notice how the total comes very close to being equal to zero? This is
what I'd expect. If you pretend the input delay of the DLL pad is
also .7, then suddenly the total for clk1 is a slightly positive
number, just like clk2.
Any hints on this from anybody? Is the Xilinx timing file wrong on
Tiodll?
Have fun,
Marc
Article: 42631Back in '94 I needed to do just that - convert a significant ABEL design to MAX7000 parts. We bought the Altera fitter add-on to Data I/O's ABEL package and started doing so. However, the "fitter" just took the optimized logic file from ABEL and re-compiled it in Altera's Max+Plus II. The (frequent) error messages referred to the intermediate logic file and were of limited use and lots of frustration. Finally, after a week or so of effort I spent a day converting the numerous ABEL files to AHDL and compiled them in Max+Plus II directly. The results fit better, were easier to understand, and - frankly - were much easier to create. A bonus was that the source was smaller, clearer, and more understandable as well. Having spent years using ABEL and AHDL, I strongly perfer the latter. The only downside of course is that it locks you into Altera's parts. But if you're going to use them anyway, it's a good way to go. Besides, translating between the two languages that are so doggone similar is simple anyway. Jim HornArticle: 42632
Hi, Kevin, I was not accusing you, I was just annoyed at the whole issue, which really is a non-issue: The Spartan-II shows correctly in Fig. 2 of its data sheet, that the internal OE control signal is active High. ( Anybody should be able to deduce that this imlies that the 3-state control is active Low). It also says that polarity can be controlled by software. I looked at the detailed schematic. You can flip around the polarity of: •the T or OE input •the D of the OE-control flip-flop •its CE •its clock •its S/R input •the direct O signal •the D of the data output flip-flop •its CE •its clock •its S/R signal that is shared with the OE-control flip-flop and the Input FF • the CE of the input flip-flop •and its clock. In other words, you can change almost any polarity in the whole I/O. But we tacitly assumed that everybody knows the big difference between Output Enable and Tristate. They are not the same thing, they are the opposite of each other ! Maybe we should have included a tutorial... That's what I meant by "silly misunderstanding" Peter Alfke, Xilinx Applications ============================== Kevin Brace wrote: > > Life is too precious to be wasted on such silly misunderstandings. > > What do you mean? > Are you saying that I should have known that Virtex IOB tri-state > buffers are active low? > I think what I said previously should have been included in Spartan-II > datasheet. > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.) > > Peter Alfke wrote: > > > > It's the old confusion between output enable and tristate, which obviously are the > > opposite of each other. But we should, therefore, make it redundantly absolutely > > and perfectly clear that active High OE is identical with active Low 3-state ( and > > vice versa). > > Life is too precious to be wasted on such silly misunderstandings. > > > > Peter Alfke, Xilinx Applications > > =============================================Article: 42633
My design uses a Spartan-II configured from a PROM, and I'm using a clock DLL in the FPGA. I have had some problems that I believe are due to power-up initialization, so I'm trying to come up with a fool-proof scheme to handle power-on config and reset. Here's my plan: 1. My board has a power-supply supervisor, which I will connect to the PROGRAM input. This will hold off loading configuration until well after the supply is stable, and in case the power ever glitches, the FPGA should re-load itself. 2. In BitGen, I will set LCK_cycle to 1, so that the startup after configuration will wait until the DLL is locked. 3. I will connect the DONE signal to an input, where I will invert it and synchronize it and use it as the internal reset for my circuits in the FPGA. 4. I will set GTS_cycle = 2, GSR_cycle =3, and GWE_cycle = 3. I will set DONE_cycle = 6. Therefore, my internal reset will be asserted until a short while after the DLL is locked and the GSR is released. Anyone see a problem here? Thanks, Barry BrownArticle: 42634
There is a new tool in the 4.2i software called DATA2BRAM that should address your needs. It is documented in the online docs at: http://toolbox.xilinx.com/docsan/xilinx4/data/docs/d2b/d2b.html I would take a look at this utility and see if it fits your requirements. -- Brian Paul wrote: > Hy, > > I am using a ROM in my design on a VirtexE-1000. This ROM is made as a > RAM block where the WE signal is always inactive. To write the initial > value to the ROM I regenerate the core (core generator) assigning a > new init file to the memory. The problem is that doing it I have to > re-synthetize and P&R the whole design everytime I want to change some > value in the ROM. Is there any way to change the ROM content without > synthesis and P&R?? (I am using Xilinx ISE 4.2 tools and the XST > synthetizer) > > Thaks in advance!! > Paul.Article: 42635
hi, I'm using the Quartus II simulator to simulate my design. My design has grown and reached a point where I need to load up a thousands of different input vectors for a specific input. It would be a waste of time to try and do this manually. Is there a smart way to load many input vector values on a single input in the waveform editor of Quartus II waveform editor ? Thanks, PrashantArticle: 42636
Please allow me to follow up with interesting information from Eric Crabill: From a primitive point of view, the IOB has a "T" input. All of the primitives in the library have "T" inputs. It really is a "T" (TRISTATE) signal, active high. 1. As far as I am aware, you cannot change the polarities by what you do in the design, short of using FPGA Editor. 2. If you are in schematics, all the library elements have a "T" pin on them, so you would probably just implement a tristate logic function to directly control the I/O. This is somewhat natural and obvious. But most people are not using schematics anymore... 3. If you are in HDL-land, here is one example of what a designer might do: assign bidir = my_oe ? my_value : 1'bz; In this case, the synthesis tool probably generates the following circuit: my_oe ---> inverter ---> T pin on I/O primitive Here, the inverter can be pushed forward into the IOB by the mapper, using the local inversion (instead of a separate lut). It is also possible that either the mapper or the synthesis tool could push the inverter backwards into the logic that was driving my_oe. If you are in HDL-land, here is another example of what a designer might do: assign bidir = my_t ? 1'bz: my_value; In this case, the synthesis tool probably generates the following circuit: my_t ---> T pin on I/O primitive Here, there is no need for inverters anywhere, so nothing special is done, and this logic is what gets implemented. I think the idea of those local inverters in the IOB is that the CAD tools can compensate for a designer who is not aware of the architecture. If the local inverters did not exist, the coding style of the HDL designer would impact the circuit performance (that extra "inverter" would cost something in terms of delay, because it would be in a LUT). EricArticle: 42637
I agree that this is priceless, but... Is it possible the IP address was spoofed? I don't know a lot about it, but I am mostly posting as a test by repeating the apparent steps that "Hideout" followed: 1. Get a generic email account www.usa.com. (I used netscape.net) 2. Register the generic account with google groups. 3. Post to google groups. (I am just a curious Xilinx employee.) Brian Drummond <brian@shapes.demon.co.uk> wrote in message news:<g83lcugkcdlhmi5sb75fh7eblc4c5spmhl@4ax.com>... > On 25 Apr 2002 18:47:09 -0700, hideout@usa.com (SECRET) wrote: > > >Hi, > > > >I noticed that Xilinx is claiming on their website that they have a > >Vertex II PRO with a 3.125 Gbps Transceiver and up to 4 IBM PowerPC > >Processors? Can you actually get silicon for this or is this just > >Marketing BS? > > > >(do not e-mail me.. just post here) > > > >>Hideout< > > Priceless... > > Turn the headers on. See a line that says > NNTP-Posting-Host: 66.35.226.228 > > Try a lookup... > > IP address: 66.35.226.228 > Official name: ip66-35-226-228.altera.com > > > oops! > > - BrianArticle: 42638
In article <1259ab37.0204291508.3700008a@posting.google.com>, Davis Moore <davisbmoore@netscape.net> wrote: >I agree that this is priceless, but... > >Is it possible the IP address was spoofed? The posting is done through google, and google's newsgroup poster does log the IP, so this initially suggests that it is through the given IP. IP address spoofing is a lot harder when you want to convey information, not just forge a SYN (connection request). It may be possible (I'm not sure how sequence numbers are defined), but would be very vulnerable to dropped packets and other issues. My bet is that it is some intern at Altera, thinking it would be a funny joke. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 42639
It's not germ warfare yet, but it is getting closer... :-( Peter AlfkeArticle: 42640
Hi Len, It is definitely possible to disable the bus-hold circuitry in all 9500XL devices. Disabling the bus-hold circuit has always been physically possible - It's just that we didn't advertise it as such when the devices first came out. Now it's a feature in software because people have asked for it... Best Regards, Mark Len Chisholm wrote: > Hi all, > > While searching for some detailed information about the 9500XL family, > I tripped over an item in the Answer Database containing a very > interesting comment. > > Answer #5175 "CPLD XC9500XL/XV - What is the bus-hold circuit?" has > the following paragraph : > > This bus-hold circuit is always enabled during normal operation. To > turn this feature off, select the "Disable BUSHOLD Circuit" option > under the "Generate Programming File" process properties in Project > Navigator. This option is only available as of 4.1i Service Pack 2. > > However, the data sheet for the 9500XL family does not say that this > is possible - although the data sheet is dated June 1999 and > sub-titled "Preliminary Product Specification" > > Can anybody shed any light on this ? > > I'd like to know if it is really possible to disable the bus-holders > in the 9536XL - this would be extremely useful to me. I'm surprised > that this information seems to have only become visible in November > 2001 ( the date of the answer record ). > > Is it that somebody has only just realised that it is physically > possible, that somebody has finally asked for it, or that it is only > available in more recent revisions of the chip ? > > Hoping for the right answer :-) > > Len Chisholm.Article: 42641
Isn't it time to move to an HDL-based simulator? Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.)Article: 42642
Hi all, I'm interfacing the Spartan-II over a PC/104 bus as an IO device. In my logic there is a finite state machine that for all intents and purposes should never be stopping no matter what happens. It just relies on a counter to trigger it and it goes, and the counter isn't stopping. This FSM just triggers an external A/D-converter and writes samples to a FIFO in the FPGA. It doesn't test for a full FIFO as the FIFO doesn't allow writes if it's full anyway, so we just let it run nonstop regardless of the fullness state of the FIFO. Therefore it should never stop. However, for some reason at a certain point in the program this FSM just stops going for no apparent reason. The system reset is staying low and the trigger for the FSM is still going, the FSM just mysteriously stops! This Spartan-II is on a device that is connected to a PC on a card running software that writes samples retrieved from the FPGA onto the D: drive (a compact flash card set as the slave drive on the IDE bus). Since this is the PC/104 bus it appears the IDE and ISA signals are shared (not sure if this is the case in a regular PC or not). I noticed that it looks like the crash could possibly be happening when there is a write to the compact flash card. Could I be doing something really wacky because the Spartan is responding to IDE bus signals? If so, would I need to compensate for this by decoding the IRQ14 signals or maybe the IDECS0# or IDECS1#. I haven't been able to find a good resource for IDE information, so if anyone could point one of those out too it would be great. I'm not sure if this IDE thing is my problem, but at this point it's about the only thing I can think of that would even remotely be causing this behavior. Thanks alot. SeanArticle: 42643
Hi:
I am learning Power Compiler from Synopsys. My example is a 5-bit
ring counter at 200MHz and a synchronous Add-1 counter. The counter
is supposed go to zero and continue when it reaches 19.
Does it mean if I estimate the switching rate at the five registers in
each design, and run report_power, it will generate me the correct power
report?
My constraints are 1)
include syn_1.scr
create_clock -name clk_100m -period 10 -waveform {0 5} {clk_100m}
set_switching_activity -clock clk_100m -toggle 0.5 -static 0.1 S0
set_switching_activity -clock clk_100m -toggle 0.25 -static 0.1 S1
set_switching_activity -clock clk_100m -toggle 0.125 -static 0.1 S2
set_switching_activity -clock clk_100m -toggle 0.0625 -static 0.1 S3
set_switching_activity -clock clk_100m -toggle 0.03125 -static 0.1 n982
report_power > myfile.log
2)
include syn_2.scr
create_clock -name clk_100m -period 10 -waveform {0 5} {clk_100m}
/* Does it mean their switching activity are same in the two counters? */
set_switching_activity -clock clk_100m -toggle 0.5 -static 0.1
swl_counter_reg[0]
set_switching_activity -clock clk_100m -toggle 0.25 -static 0.1
swl_counter_reg[1]
set_switching_activity -clock clk_100m -toggle 0.125 -static 0.1
swl_counter_reg[2]
set_switching_activity -clock clk_100m -toggle 0.0625 -static 0.1
swl_counter_reg[3]
set_switching_activity -clock clk_100m -toggle 0.03125 -static 0.1
swl_counter_reg[4]
report_power >> myfile.log
I am wondering what are the difference in their power report? I found the
add-1 counter
is 150uW, ring counter takes 140 uW. Is this a reasonable number? What is
the gain in
power consumption when people choose ring counter instead of normal?
Please attach to cobraxu@singnet.com.sg
Thanks
Kelvin
Article: 42644In article <3CC421BB.E48790FD@xilinx.com>, Austin Lesea <austin.lesea@xilinx.com> writes: >Hal, > >I wish I had the answer to that. Complex chips = complex bypassing. >Believe me when I say we are working on it. Life would get boring if we didn't have problems like this. :) >The hole in the center is great for hiding a bunch of bypass. > >Blind or hidden vias a re great for that as well (caps on the back of >the board). I'm having troubles picturing how to use blind/burried vias to get better bypassing. If the BGA is on one side of the board and the bypass caps are on the other, blind vias are evil in the sense that they prevent connecting the BGA to the cap which is the whole object of the bypass cap. Are you thinking of something like using blind vias where full length vias would otherwise collide with the pads for the caps? And (magically/luckily) placing each cap so it hits a couple of appropriate (non blind) vias from the BGA? Any estimates on the cost of using "a few" blind vias for something like this? >0402 is better than 0603 for SM caps (smaller is better, less >inductance, and you can pack more on the pcb). Got any numbers? How does N 0402 caps compare with M 0603 caps, assuming vias-in-pads? What if I use 2 vias per pad on the 0603? >Austin Thanks. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 42645
You can use a .vec or .vwf file which is just a text representation of the signal transitions. Edit this and use it as stimulus to your simulation. Results will still get displayed. (You can start by saving your current waveform as a .vec/.vwf and looking at the results/modifying it. IMHO however you might want to consider using another simulator that supports more functions of a testbench. You write a test bench in your HDL which provides the waveforms and/may even check the results of the Device Under Test. I used to exclusively use waveform entry, but it really becomes limiting for larger designs and almost impossible to do hierarchical testing. Paul "Prashant" <prashantj@usa.net> wrote in message news:ea62e09.0204291455.4f95879@posting.google.com... > hi, > I'm using the Quartus II simulator to simulate my design. My design > has grown and reached a point where I need to load up a thousands of > different input vectors for a specific input. It would be a waste of > time to try and do this manually. > > Is there a smart way to load many input vector values on a single > input in the waveform editor of Quartus II waveform editor ? > > Thanks, > PrashantArticle: 42646
>Aw, come on. Be serious for a moment. > >Is 2 Mbytes enough for video, or is that just not even close for >something like a high performance MPEG4 coder? Is 1 Mbyte enough for a >packet processor? What if you are using a 405PPC? How much code space >do you need for a control program? For a DSP support program (with all >of the hard stuff in the FPGA like the FFT cores, etc.)? > >If you look at SDRAM prices, are you willing to pay twice the commodity >price in an FPGA? Three times? How much is it worth to you? > >I already know that programs grow to fit the available memory space, and >that data grows to fill the disk..... There is obviously an chicken and egg problem. If you put X bytes of RAM on the chip, then people will dream up ideas to use it. Some of them won't fit so there will be a market for chips with more RAM. I remember a story about Motorola... Nothing firm, just a rumor, but it seems reasonable. They had a good collection of "cores" for their small micro family. If you would sign up to purchase enough of them, they would build whatever you wanted from their collection of cores and make it into a standard product - n A/D, y counters, x ROM, y RAM... Whatever you wanted from their chinese menu. You got normal product type support and documentation. They got a guaranteed order to cover (some of?) the NRE. That sort of chinese menu approach might make sense for something like Easypath. For example, you could take chips with broken RAM, zap a few links, and sell them as no-RAM (or smaller RAM) versions. If volume gets high enough you can make a special/cheaper die. Same for multipliers, and maybe PowerPC cores. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 42647
Sean A Laughter wrote: > > Hi all, > > I'm interfacing the Spartan-II over a PC/104 bus as an IO device. In my > logic there is a finite state machine that for all intents and purposes > should never be stopping no matter what happens. It just relies on a > counter to trigger it and it goes, and the counter isn't stopping. This > FSM just triggers an external A/D-converter and writes samples to a FIFO > in the FPGA. It doesn't test for a full FIFO as the FIFO doesn't allow > writes if it's full anyway, so we just let it run nonstop regardless of > the fullness state of the FIFO. Therefore it should never stop. > However, for some reason at a certain point in the program this FSM just > stops going for no apparent reason. The system reset is staying low and > the trigger for the FSM is still going, the FSM just mysteriously stops! > > This Spartan-II is on a device that is connected to a PC on a card running > software that writes > samples retrieved from the FPGA onto the D: drive (a compact flash card > set as the slave drive on the IDE bus). Since this is the PC/104 bus it > appears the IDE and ISA signals are shared (not sure if this is the case > in a regular PC or not). I noticed that it looks like the crash could > possibly be happening when there is a write to the compact flash card. > Could I be doing something really wacky because the Spartan is responding > to IDE bus signals? If so, would I need to compensate for this by > decoding the IRQ14 signals or maybe the IDECS0# or IDECS1#. I haven't > been able to find a good resource for IDE information, so if anyone could > point one of those out too it would be great. > > I'm not sure if this IDE thing is my problem, but at this point it's about > the only thing I can think of that would even remotely be causing this > behavior. Thanks alot. > > Sean Hi Sean, I don't know what kind of computer system you are using, but according to your description it is no real PC/104 bus since there are no IDE signals in PC/104 (see specification at http://www.pc104.org/technology/PDF/PC104Specv246.pdf). You should look in the documentation of your board since there seem to be done some proprietary extensions by the board vendor. Since IDE can be easily derived from the ISA bus (and PC/104 is nothing else, just in a different format with some electrical characteristics changed) it could be that the manufacturer simply used some logic gates to generate IDECS0# and IDECS1# from address lines above SA2 and added them to the original PC/104 signal. How this decoding is done exactly should be stated in your manuals (at least I would expect to find it there). Some information about the IDE bus you can find at http://ata-atapi.com or at http://www.t13.org . Good luck, JensArticle: 42648
Hal Murray wrote > Any estimates on the cost of using "a few" blind vias for something > like this? Not as much as it used to be :) Fairly mainstream technology now. As someone else noted, fan the inner balls inwards, then the outer balls outwards, generating a little 'ring' for the caps. > >0402 is better than 0603 for SM caps (smaller is better, less > >inductance, and you can pack more on the pcb). > > Got any numbers? How does N 0402 caps compare with M 0603 caps, > assuming vias-in-pads? What if I use 2 vias per pad on the 0603? Lots of good info on the PhyComp site (ex-Philips Components)Article: 42649
Hi all, For Virtex, are there any issues regarding powering up the different voltage supplies in different orders? What sort of component can be use for supplying the Virtex? best regards, YD
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