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 those who want to build a linux hardware ref. platfrom for Virtex 2Pro ML300 the reference desing for Xilinx EDK does exist - just received it. it should be sufficient to run Montavista distribution, but I guess denx ELDK would also work with minor patching. antti this reference design really is available from your local Xilinx FAE! (I didnt believe it until got it)Article: 59576
Actually, the University that I am currently at uses the Xilinx to implement 'simple' circuits as our lab experiments. We do things like decoder, ring counter and stuffs. The XC3000 is more than enough for such jobs. As students, we are at a learning stage, thus we wouldn't know how to use the more advanced Spartan or XC4000 or etc even if those are given. Thanks for your comments. Puting all those aside. I am now having this ISE 4.2i student edition software which doesn't come with the XC3000 parts diagrams. My school uses Xilinx Foundation Series 3.11. Is there any way that I can import the XC3000 diagram parts, do the schematic at home, make sure that it is 'implementable' and then transfer the .sch file back to school for the actual testing on the Xilinx chip? Thank you. Peter Alfke wrote: > The XC3000 is to a modern FPGA what a '286 is to a Pentium4. Would your > professors suggest you use a '286? It's a capable computer, but > hopelessly obsolete and underpowered. So is the XC3000. > Get with it and use Spartan or Virtex devices. > "One year in the life of an FPGA is like 15 years in a human". > By that rule, your XC3000s should be in the old folks' home or the cemetary. > > Peter Alfke, Xilinx > ===================== > Terry wrote: > >>How to I design a circuit involving XC3000 with Xilinx ISE student >>edition? I look through the components and parts, but couldn't find the >>XC3000 series. I only found Virtex, Spartan, XC4000 but not XC3000 series. >> >>And also, my school uses Xilinx Foundation Series software for designing >> circuits with XC3000. Is it possible for me to save the .SCH file >>from school and open it in my Xilinx ISE student edition? and vice versa? >> >>Thank you.Article: 59577
Isnt the proper way to do this... ---- # SLEW sets the speed of an IOB output rise/fall time. NET mysignal slew=FAST; # Legal values: FAST, SLOW. # FPGA Families: All. # Applies to output and I/O pads or the net connected to an output pad --- The pad report indeed says that I have a fast slew rate on the pad ive designated to have the fast slew rate attribute. alternatively you could use the constrain editor to edit your ucf file and add, with the advance option, the required constrain that you want, in this case the fast slew rate. Both gives you the same end result. jacques. stephen@postec.co.nz (Stephen du Toit) wrote in message news:<798f0979.0308211905.d2b451@posting.google.com>... > Hi, > > If someone can help me with this, I'll be very happy. > > I would like to change the slew rate of some of my output pins of a > SpartanII to "FAST". Tried to put it in the UCF file, it obeys all the > other constraints that I put in there, but not the "FAST" one. The > syntax used was > NET "c" FAST; > > I also declared some stuff in my VHDL source as follows: > attribute FAST : string; > attribute FAST of c : signal is "true"; > > I looked at the properties of the Place-and-route but cannot find > anywhere where the option has to be enabled. > > The software is happy with all of this, but the PAD report still says > that pin c is "SLOW". > > Thanks very much. > > Stephen du Toit > > > I triedArticle: 59578
Serial interface can be used to reconfigure partially the FPGA. I did some tests using reconfigurable modules generated by Modular Design flow and the FPGA has been reconfigured correctly. Regards Eduardo Wenzel BriãoArticle: 59579
Hi I developed a project using one fixed area and two reconfigurable areas. But when the Assembly Phase of MD flow is executed, the PAR tool issued the following error: FATAL_ERROR:Guide:basgitaskphyspr.c:369:1.17.4.3:137 - Guide encountered a Logic0 or Logic1 signal GLOBAL_LOGIC1_6 that does not have a driver or load within the module boundary. This problem may be caused by having a constant driving the input from outside the module boundary or because a driver or load comp did not meet the par-guiding criteria. The design will not be completely placed and routed by Par-Guide Process will terminate. To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com. If you need further assistance, please open a Webcase by clicking on the "WebCase" link at http://support.xilinx.com I am following all the steps of XAPP290 document. Modular Design flow generated some partial bitstreams, but the PAR error is issued in the final phase of M.D. Can someone help me in this thread? Eduardo Wenzel BriãoArticle: 59580
I am in the telecom business where redundant clocks and clock protection switchovers is big issues. That leads to several problems when using Xilinx FPGA's an DCM's. One example is when clocks are lost and comes back again, the DCM then need a reset to start the lock procedure. It is possible to make a circuit which checks the DCM status and give a reset when LOCKED is low, but it takes resources. We have in fact seen a few times that the STATUS bits from the DCM indicated OK, but the output clock was not OK until we gave the DCM another reset. So Xilinx: Why cannot the DCM itself start to "hunt" for a lock as soon as lock is lost?? The DCM's are nice though, could not achieved my I/O timing without them!Article: 59581
Hi guys, How to get around this error, I try to instantiate a LVPECL output and always get the error during bitgen phase. The UCF file already constrained output net IOSTANDARD = LVPECL and LOC=P56 (XCV100E-PQ240) For my understand, we just need to instantiate the P site only. Is that true? Running DRC. ERROR:DesignRules:441 - Blockcheck: Illegal LVPECL configuration. Comp P_OUT is configured as a LVPECL IOB that uses the OUTMUX, but it's slave site P57 is empty.Article: 59582
Hi there
I am using Xilinx Webpack / Modelsim Starter Edition / Spartan IIE-7fg456
development board.
I have made a design in VHDL, consisting of various buffers, fifos, control,
timers and counters.
I want to start the timing simulation process by just looking at a single
module (the simplest - a downcounter - code below).
The functional simulation in Modelsim works fine (I wrote the simple
testbench myself), but despite it appearing to meet the timing requirements
I placed in the constaints file, the post translate/map/p&r models seem to
have longer delays than expected.
I.e. the counter starts counting after an enable goes high - this happens
on the next clock cycle as expected in the functional simulation, but is
delayed by several clock cycles in the timing simulations, despite meeting
constraints that are less than one half clock cycle. I need to run the
clock at 100 MHz (10ns period).
Then I thought that the mapping process is mapping the ports of the module
to actual physical i/o with its associated delays, whereas in fact this
module is a component in the module the next level up. Could this be
causing the apparent problem? If so, is there any reliable method to
simulate a single module that forms part of a design, other than at the
functional level?
I apologise if this seems a basic question, I am trying to learn the best I
can.
Many thanks for your help
Tom
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity downcounter is
Port (
CLOCK_IN : in std_logic;
LOAD_IN : in std_logic_vector(13 downto 0);
LOAD_ENABLE_IN : in std_logic;
Q : out std_logic;
RST : in std_logic
);
end downcounter;
architecture Behavioral of downcounter is
attribute uselowskewlines: string;
attribute uselowskewlines of Q : signal is "yes";
begin
process (CLOCK_IN, RST)
variable COUNT : std_logic_vector(14 downto 0);
begin
if RST='1' then
COUNT(14 downto 0) := "100000000000000";
elsif (CLOCK_IN='1' and CLOCK_IN'event) then
if COUNT(14) = '0' then
COUNT := COUNT - 1;
elsif LOAD_ENABLE_IN='1' then
COUNT(13 downto 0) := LOAD_IN;
COUNT(14) := '0';
COUNT := COUNT - 1;
end if;
end if;
Q <= not(COUNT(14));
end process;
end Behavioral;
Article: 59583Joseph H Allen wrote: > > In article <3F416E2C.12F31ABC@andraka.com>, > Ray Andraka <ray@andraka.com> wrote: > >Add to the list: > > Cutting out half the LUT RAMs/SRL16s in SpartanIII > > Yeah this was a bad idea. Hey, it works for me. My understanding is that this helps save a lot on price. It is a rare design indeed that needs the SRL16s or LUT RAMs from more than half the chip. Or you could look at it a different way. Think of the Spartan 3 chips as having half the number of FF/LUTs (with full SRL/RAM function) that the spec says and then they give you that many more (limited versions) for free! I expect the Spartan 3 will still be a much better price point than the Virtex II. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 59584
HI mates, I am using 12 same entitites using Component decleration method. I am giving input to 12 entities in such a way that the internal signal's in each entity has different values from each other at any time. Now the top vhdl final in which all the component decleration are defined , I want to use the internal signal's of each block to perform some calculation. The probelm is that in each of the 12 entities signal has the same name (as I am using component decleration method to generate same entity 12 time). How to access the internal signal of say Component1 , Component2 or so on. in the top entity. Is there is any way to access these Signal in VHDL? Any suggestions will be Appreciated . Rdgs IsaacArticle: 59585
Hakon, I would be intersted to know what the conditions were where the status bits did not indicate that the DCM was not functioning properly. The overflow bit, the DLL not in phase bit, and the CLKIN lost bits are all required (in addition to the LOCKED signal) to determine that the DCM is functioning properly (if it is likely or normal to have the incoming clock mis-behave). Also there is the CLKFX stopped bit if you are using that output. I spent 23 years in telecom, and clock signals can fail in the most strange ways (as microwave links fade in and out, for example), so I understand that we may not have covered 100% of the odd behaviour of the world's transmission systems. For that reason one adds user logic to solve the unusual user problems that are out there. In a system that I designed, I needed to monitor embedded switch clock commands, AIS, frame errors, bit errors, clock loss, clock frequency, and clock rate of change of phase. If any of these parameters exceeded a user defined threshold, we needed to switch to another (better) clock and report the problem. Once switched, we were not allowed to switch back until the problem was not only resolved, but a user defined time had elapsed. There is no way to design all of this for you, but we will supply the necessary status bits. If any of these bits did not work as expected, I would like to know. Austin Hakon Lislebo wrote: > I am in the telecom business where redundant clocks and clock > protection switchovers is big issues. That leads to several problems > when using Xilinx FPGA's an DCM's. One example is when clocks are lost > and comes back again, the DCM then need a reset to start the lock > procedure. It is possible to make a circuit which checks the DCM > status and give a reset when LOCKED is low, but it takes resources. We > have in fact seen a few times that the STATUS bits from the DCM > indicated OK, but the output clock was not OK until we gave the DCM > another reset. > So Xilinx: Why cannot the DCM itself start to "hunt" for a lock as > soon as lock is lost?? > > The DCM's are nice though, could not achieved my I/O timing without > them!Article: 59586
Comments inline, additional at the end. "Jacques athow" <jaxlau@yahoo.com> wrote in message news:acc717b2.0308220345.6d058151@posting.google.com... > Isnt the proper way to do this... Sure it is, there's just more than one way to do it. Your way is valid for the FPGAs but not the CPLDs. The original poster's method of "NET yadayada FAST;" should work as should "INST yada_obuf FAST;" both of which I use withouth problem. > ---- > # SLEW sets the speed of an IOB output rise/fall time. > > NET mysignal slew=FAST; > > # Legal values: FAST, SLOW. > # FPGA Families: All. # CPLD Families: None. > # Applies to output and I/O pads or the net connected to an output pad > --- > > The pad report indeed says that I have a fast slew rate on the pad ive > designated to have the fast slew rate attribute. > > > alternatively you could use the constrain editor to edit your ucf file > and add, with the advance option, the required constrain that you > want, in this case the fast slew rate. Both gives you the same end > result. > > jacques. > > stephen@postec.co.nz (Stephen du Toit) wrote in message news:<798f0979.0308211905.d2b451@posting.google.com>... > > Hi, > > > > If someone can help me with this, I'll be very happy. > > > > I would like to change the slew rate of some of my output pins of a > > SpartanII to "FAST". Tried to put it in the UCF file, it obeys all the > > other constraints that I put in there, but not the "FAST" one. The > > syntax used was > > NET "c" FAST; > > > > I also declared some stuff in my VHDL source as follows: > > attribute FAST : string; > > attribute FAST of c : signal is "true"; > > > > I looked at the properties of the Place-and-route but cannot find > > anywhere where the option has to be enabled. > > > > The software is happy with all of this, but the PAD report still says > > that pin c is "SLOW". > > > > Thanks very much. > > > > Stephen du Toit > > > > > > I tried Did you set the IOSTANDARD for those signals? The propagation rules and applicable elements are the same for those two attributes. I'm wondering if the net name ended up being something different by the time it got to the pad, making the propagation rules inapplicable. If you can see the net names in FPGA Editor but your IOBs are still SLOW, try using the INST format on the OBUF, OBUFT, IOBUF, or IOBUFT primitives that were generated by your VHDL code. If all the other constraints are showing up properly, is there somewhere you have a SLOW that might inadvertantly be overriding the constraint? If the timing constraints are succussful, the checkbox for "Ignore Timing Constraints" in the GUI probably isn't checked so that shouldn't be a problem either. I hope you find what's going on!Article: 59587
Peter Alfke <peter@xilinx.com> wrote in message news:<3F4550A6.DA275722@xilinx.com>... > Grrrrr! :-( > Buaaaahhhhh! C'mon Peter, everybody can make a mistake or two. I think you don't want to pay that champagne! (An old post, if you don't remember.) Luiz Carlos.Article: 59588
You are missing some key pieces of information: the available clock frequency
(this is different than the sample rate), and the target FPGA family.
A MAC type filter will occupy a fixed amount of real-estate for any number of
taps, but will take additional clock cycles for each sample as taps are added.
A DA filter runs in the same number of clock cycles (equal to the number of
bits in the input for a serial DA) regardless of the number of filter taps, but
requires more area as the length of the filter is increased. The DA filter
also computes the sum of the partial products to full precision where the MAC
generally does not, although it may not be significant in your filter.
Ideally, you should be clocking the FPGA much faster than the 5MHz so tht you
can take advantage of serial arithmetic to reduce the physical size.
CIC filters are merely a recursive solution to a boxcar or moving average
filter. In those filters, you add the N previous samples and divide by the
number of samples. In the case of the CIC, there is no division, so there is a
net gain of N in the basic non-decimating CIC. Now getting a bit fancier, you
can suck the decimation into the filter so as to reduce the size of the
delays. In that case, the filter is equivalent to a N*R tap boxcar filter
whose output is sampled every R input samples. In this case, the gain is N*R.
Then, if you cascade CIC sections, you multiply that gain by the gain of each
section, so for an M section CIC, the gain is |N*R|^M. The gains and the
filter responses can be easily derived using the equivalent boxcar filters and
decimation or interpolation stages.
Sasa Bremec wrote:
> Hi!
>
> I have an question about the main differences between this two filter
> architecture.
>
> In my design I would like to minimize slice resources used by the filter
> also I have to take in consideration that my sampling frequency.
>
> The MAC filter is ideal for my requirements but I would like to hear some
> more opinion about that.
>
> Filter details:
>
> Filter type: FIR (raised-cosine)
>
> Filter order : 32
>
> Sampling freq.: 5 MHz
>
> Decimation rate: 4
>
> I also have a question about CIC filter and its related CIC Gain, if anyone
> can help me understand this issue, I would really like to know more about
> it.
>
> Best regards, Sasa
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 59589
Only if your clocking is perfect. You need to add the maximum jitter on your
clock to the minimum period to determine the minimum period in your system.
Don't forget to add the additional jitter added by the DCM or DLL.
smu wrote:
> Hello,
>
> I'm new in the fpga design and have a question about the timing summary from
> ise 5.2 from xilinx.
>
> Are the minimum period of a final design announced by the software bundle
> realistic ?
>
> Thank you in advance
>
> smu
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 59590
Use the command strobes like you are as the clock to an input register, but
also toggle a toggle flip-flop with the command. Use the address and any
qualifiers to produce the clock enable to both the input register and the
toggle flip-flop. The toggle flip-flop switches state each time a valid
write is performed. Resync the toggle flip-flop output to your local clock,
and then run it into a simple state machine that generates a 1 cycle wide
pulse as a response to a change on the input. That pulse , which is sync'ed
to your local clock can then be used to validate the contents of the input
registers. I usually use it to copy the input register contents to a second
layer input register that is clocked by the local clock. It is also used in
your control logic to let the rest of the circuit know that there is new
write data. As long as the bus write frequency is less than about 3 cycles
of your local clock this works fine as described. If the bus can write
faster, then you can write successive writes into a shift register or memory
and transfer to the local in parallel every Nth write.
rickman wrote:
> After reading a post by Jonathan Bromley on the VME interface, I thought
> I would see if anyone had any comments on a design I am doing. I have
> to interface to the PC104 bus which is just the PC ISA interface on a
> small board. After beating my head against the wall for a couple of
> trys, I decided to dump the BCLK since it is not really part of the spec
> and treat the command stobes as async lines. My design is further
> complicated by the fact that my system clock ranges from 2 MHz to 50 MHz
> to allow power conservation.
>
> I finally decided that the only way to get the job done was to treat the
> command strobes as clock lines. Read cycles are done normally by muxing
> the data from various registers based on the address lines and the
> tristate outputs are controlled with the strobes. Writes to simple
> registers are done on the trailing edge of the write strobe. For reads
> that need to update or clear bits, a strobe is generated that is sync'ed
> to the system clock using a circuit to remove the metastable problem.
> The same circuit works with writes that need to set flags or control
> FIFOs.
>
> I don't see any problem with any of the circuits I have used. I don't
> even see the need to use a clock tree for the command strobes since
> there are no race conditions where a few ns will matter. Unless there
> are *huge* differences in routing delays, this circuit should work just
> fine.
>
> Anyone had big problems with similar async circuits? BTW, here is the
> simple sync circuit to generate a single pulse in the target clock
> domain regardless of the relative speed of the clocks.
>
> |------- Metastable -------|
> __________
> | | _____
> |------O| inverter |-------|---------------| | Pulse
> | |__________| | | XOR |---->
> | ______ ______ | ______ |--|_____| Out
> | | | | | | | | |
> |---| D Q |-----| D Q |--|--| D Q |--|
> Strobe | | | | | |
> /Clock | | | | | |
> -------|> | ---|> | |---|> |
> |______| | |______| | |______|
> | |
> |___________|___________ Output Clock
>
> The pulse out should be clean by the next clock edge as long as the
> routing is kept short. Or if the clock period is very short another FF
> can be added to feed the other leg of the XOR gate and assure a clean
> output.
>
> If the input clock is faster than the output clock, extra clock edges on
> the input will be ignored until the signal has clocked through the other
> clock domain.
>
> You can also tap the second FF for the feedback if you want to use it
> for a handshake. A second FF on the input side and an XOR gate will
> give you a pulse on "acknowledge" of the pulse crossing the clock
> domain.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 59591Microwaving is definitley the way to go. You probably want to make sure it is an old microwave, just in case. Ian Poole wrote: > I know this is off topic, but MICROWAVE it. > See http://www.hamjudo.com/notes/cdrom.html > Obviously its extremely dangerous and bad for you, so don't do it because I > said it sounded fun... > > Ian > > "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message > news:jJ%Za.709$0t7.279@newssvr25.news.prodigy.com... > >>I would also like to find out what the status of W2K/SP4 support might be. >>I'm getting ready to jettison Win XP (big mistake, don't ask) in favor of >>going back to W2K. I'm looking for a really creative way to destroy the > > Win > >>XP CD, something commensurate with what I think of the product. One > > thought > >>I had was to attach it to a high speed motor and let centrifugal force > > shred > >>it to pieces. That ought to be fun. >> >> >>-- >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>Martin Euredjian >> >>To send private email: >>0_0_0_0_@pacbell.net >>where >>"0_0_0_0_" = "martineu" >> >> >> >>"rickman" <spamgoeshere4@yahoo.com> wrote in message >>news:3F3808AB.4FEE8557@yahoo.com... >> >>>rickman wrote: >>> >>>>I seem to recall that at one time the Xilinx tools were not compatible >>>>with Win2k SP3. Anyone know if that is still an issue? I assume it > > is > >>>>since I still see SP2 listed under the System Requirements. >>> >>>Oh, and I noticed on the MicroSoft website that Windows 2000 is up to >>>SP4. It seems like an update to the Xilinx support of W2k is needed. >>> >>>-- >>> >>>Rick "rickman" Collins >>> >>>rick.collins@XYarius.com >>>Ignore the reply address. To email me use the above address with the XY >>>removed. >>> >>>Arius - A Signal Processing Solutions Company >>>Specializing in DSP and FPGA design URL http://www.arius.com >>>4 King Ave 301-682-7772 Voice >>>Frederick, MD 21701-3110 301-682-7666 FAX >> >> > >Article: 59592
On Fri, 22 Aug 2003 06:30:32 -0700, Marlboro <> wrote: >Hi guys, <p>How to get around this error, I try to instantiate a LVPECL output <BR> >and always get the error during bitgen phase. The UCF file already constrained output net IOSTANDARD = LVPECL and LOC=P56 (XCV100E-PQ240) <BR> >For my understand, we just need to instantiate the P site only. Is that true? <p>Running DRC. <BR> >ERROR:DesignRules:441 - Blockcheck: <BR> >Illegal LVPECL configuration. Comp P_OUT is configured as a LVPECL IOB that uses the OUTMUX, but it's slave site P57 is empty. Hey Marlboro, How about learning to post via Google, so that you stop dumping HTML into this news group. (caused by problems with the Xilinx gateway to this news group) =================== Philip Freidin philip@fliptronics.com Host for WWW.FPGA-FAQ.COMArticle: 59593
Ray Andraka wrote: > > Use the command strobes like you are as the clock to an input register, but > also toggle a toggle flip-flop with the command. Use the address and any > qualifiers to produce the clock enable to both the input register and the > toggle flip-flop. The toggle flip-flop switches state each time a valid > write is performed. Resync the toggle flip-flop output to your local clock, > and then run it into a simple state machine that generates a 1 cycle wide > pulse as a response to a change on the input. That pulse , which is sync'ed > to your local clock can then be used to validate the contents of the input > registers. I usually use it to copy the input register contents to a second > layer input register that is clocked by the local clock. It is also used in > your control logic to let the rest of the circuit know that there is new > write data. As long as the bus write frequency is less than about 3 cycles > of your local clock this works fine as described. If the bus can write > faster, then you can write successive writes into a shift register or memory > and transfer to the local in parallel every Nth write. That is exactly what the diagram below does. The FSM is mearly a couple of sequential registers and the one clock wide strobe is gated at the difference point. The circuit below does not require a fast clock if you have control over the cycle length with a wait signal. That is how I am able to work with a clock range of some 20x the bus write rate to about 1.5x. The wait signal slows the bus rate to whatever rate the circuit will run at. With the async nature, sometimes it takes an extra clock before the wait signal is seen by the bus. I am pretty sure I have the kinks worked out on paper. But one problem with using the control strobes as clocks is that the software wants to use clock routing for them. We will see what happens when all the clock resources are used up. I guess I will be able to control this manually. > rickman wrote: > > > After reading a post by Jonathan Bromley on the VME interface, I thought > > I would see if anyone had any comments on a design I am doing. I have > > to interface to the PC104 bus which is just the PC ISA interface on a > > small board. After beating my head against the wall for a couple of > > trys, I decided to dump the BCLK since it is not really part of the spec > > and treat the command stobes as async lines. My design is further > > complicated by the fact that my system clock ranges from 2 MHz to 50 MHz > > to allow power conservation. > > > > I finally decided that the only way to get the job done was to treat the > > command strobes as clock lines. Read cycles are done normally by muxing > > the data from various registers based on the address lines and the > > tristate outputs are controlled with the strobes. Writes to simple > > registers are done on the trailing edge of the write strobe. For reads > > that need to update or clear bits, a strobe is generated that is sync'ed > > to the system clock using a circuit to remove the metastable problem. > > The same circuit works with writes that need to set flags or control > > FIFOs. > > > > I don't see any problem with any of the circuits I have used. I don't > > even see the need to use a clock tree for the command strobes since > > there are no race conditions where a few ns will matter. Unless there > > are *huge* differences in routing delays, this circuit should work just > > fine. > > > > Anyone had big problems with similar async circuits? BTW, here is the > > simple sync circuit to generate a single pulse in the target clock > > domain regardless of the relative speed of the clocks. > > > > |------- Metastable -------| > > __________ > > | | _____ > > |------O| inverter |-------|---------------| | Pulse > > | |__________| | | XOR |----> > > | ______ ______ | ______ |--|_____| Out > > | | | | | | | | | > > |---| D Q |-----| D Q |--|--| D Q |--| > > Strobe | | | | | | > > /Clock | | | | | | > > -------|> | ---|> | |---|> | > > |______| | |______| | |______| > > | | > > |___________|___________ Output Clock > > > > The pulse out should be clean by the next clock edge as long as the > > routing is kept short. Or if the clock period is very short another FF > > can be added to feed the other leg of the XOR gate and assure a clean > > output. > > > > If the input clock is faster than the output clock, extra clock edges on > > the input will be ignored until the signal has clocked through the other > > clock domain. > > > > You can also tap the second FF for the feedback if you want to use it > > for a handshake. A second FF on the input side and an XOR gate will > > give you a pulse on "acknowledge" of the pulse crossing the clock > > domain. > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 59594
I am working with the ACEX 1K30 and I don't understand the structure of the IOE. The diagram clearly shows three FFs; data input, data output and output enable. The three FFs even have different types of connections to the routing. But in the text, they seem to be saying that there is only a single FF in the IOE. Is there really only one FF in the IOE so that it can be either input or output? Is the OE FF always in an LE rather than the IOE? Seems like this would make for some trouble getting the timing in tight situations. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 59595
I am designing a FPGA interface for an MCU which uses only async strobes. However they are not truely async, in reality the timing to the clock is simply not spec'd. So if I understand metastability correctly, I can not use the standard circuit to reduce the failure rate to insignificant rates. Since there is a fixed relationship between the clock and the command strobes (even though it is unknown) no matter how I choose to clock the circuit, I may end up balancing the pencil well enough on end that I will see a much higher failure rate than predicted by the standard formula. My understanding is that the standard formula assumes that the two signals are not related in frequency. So the probability that they will be at the right point to cause a failure depends on the rate of each and the width of the "failure window". In my case the probability of the event being in the failure window can be very high if the timing is just right. Other than the obvious of using a separate clock for the FPGA, how can I design this circuit and get a low enough failure rate? I guess adding more time will reduce the failure rate, but how do I know how much time is enough since the standard formula does not apply? In this particular circuit I expect the strobes to change on the rising edge of the clock at about 50 MHz. Since I know nothing about the actual relationship between the clock and the strobes, I have picked the falling edge to clock the strobes into the chip. I assume that if the outputs change slightly before the clock rising edge, it will not be much and if they change later, it may be short enough to still give me close to the 3 ns setup time I need. Then a rising edge FF syncs the signal to the rest of the circuit and provides some 7 ns (out of 10 ns clock difference) for settling. I have no idea how good of an assumption this is. The output delays on the CPU may be enough to put the strobe edge right in the critical point to cause a failure. Even if I use an emperical approach and see which edge to clock on to make the circuit work, I don't know that this will operate over temperature, process, etc... I believe that some of the posts here have indicated that the "failure window" in terms of time is in the low ps (or was it fs?) range. If my circuit allows some 7 ns for settling, will this be enough to put the MTBF above 100 years in a worse case situation? Is it possible to balance the pencil well enough to make a circuit like this fail frequently? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 59599
rickman wrote: >I am designing a FPGA interface for an MCU which uses only async >strobes. However they are not truely async, in reality the timing to >the clock is simply not spec'd. So if I understand metastability >correctly, I can not use the standard circuit to reduce the failure rate >to insignificant rates. Since there is a fixed relationship between the >clock and the command strobes (even though it is unknown) no matter how >I choose to clock the circuit, I may end up balancing the pencil well >enough on end that I will see a much higher failure rate than predicted >by the standard formula. > > I think you need to make some measurements, if you can't get info from the manufacturer. Most likely, the timing will be pretty simple to figure out, as signals, especially strobes, will almost certainly either be clocked through a flip-flop right at the output, or have a minimum of gates between the last FF and the output. You really CAN'T work with so little information. What is the setup time of data and address signals from the CPU, relative to the strobes? What is the required setup and hold time of data and addresses presented to the CPU from outside? Or, do they provide all this in great detail, just never referencing any of this to the CPU clock? If you can't beat this information out of the manufacturer, then you should be able to measure it fairly easily. Jon
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