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
Talking about more practical situation, the registered and the unregisted output of a LE can be used in the State Machine implementations Ray Andraka <ray@andraka.com> wrote in message news:<3BE6AE22.5AFA3717@andraka.com>... > It simply gives synthesis and mapping more options. Often, synthesis will share the > combinatorial logic in front of a flip-flop, necessitating an unregistered connection. > With the 10K architecture, any shared logic prevents the use of the flip-flop. > > nitin wrote: > > > Hi... > > > > Well i was very much asking from the veiw point of FLEX10K and > > APEX20K architectures. U see in 10K they had one output of the LE > > going to the feedback matrix of the LLI and one output to RFTs and > > CFTs. So that meant only either registered or unregistered output > > going to the LLI feedback matrix and also to the RFT's and CFTs. > > > > But that changed with APEX20K devices where both outputs could got > > to all routing resources. Now is that becuse they wanted both > > registered and unregisterd outputs at the same time...? What was the > > need that made them to do this change in the architecture...? I > > presumed there might be circuits where one might need that. > > > > Well some more discussion on this will help a lot. > > > > Nitin. > > > > Ray Andraka <ray@andraka.com> wrote in message news:<3BE298CA.B67829D6@andraka.com>... > > > Depends entirely on your design style. For highest performance, you'll > > > generally want to avoid using the unregistered output, but that also > > > limits your design options. > > > > > > nitin wrote: > > > > > > > Hi... > > > > > > > > Can anyone tell me how frequently and where both registered and > > > > unregistered outputs from an LE are required...? > > > > > > > > Ciao, > > > > nitin. > > > > > > -- > > > --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 > > -- > --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, 1759Article: 36326
Hi everyone,
I am trying to simulate the gate-level VHDL file generated by Xilinx
P&R tools. My test design is a bunch of counters connected to an
inferred distributed-RAM. The target device is a Virtex-2 chip.
When I simulate the gate-level VHDL by itself, I get timing violation
warnings (sometimes) when writing to the distributed-RAM; watching the
simulator waveforms, it appears that the clock to the RAM has a 100-pS
phase difference to the counters' clock (the clock is routed as a
global clock net).
When I add the gate-level SDF file to the simulation, all the timing
violation warnings disappear (for all cases: min, max and typ).
Trying to trace the generated VHDL code, I see that signals are routed
through buffer entities, with built-in delays; apparently the VHDL
design itself contains all required delays.
Why would adding the SDF to the simulation make errors _disappear_?
it should be a more thorogh timing-check and find _more_ timing
errors.
Can anyone explain?
Thanks in Advance
Assaf Sarfati
Article: 36327
How critical is the timing ? You could use a frequency doubler which
generates a glitch pulse on each clock edge and count that.
Rob
htttp://www.birdcomputer.ca/
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3BE7B477.AD2BA09D@algor.co.uk...
>
>
> dfx2001 wrote:
>
> > who knows how to detect both edges (rising and falling edge) of clock in
> > verilog?
> >
> > always @(posedge clk or negedge clk)
> > counter <= counter + 1; //only count 1, not 2
> >
> > Thanks.
>
> An ``always'' block is triggered when any thing in the sensitivity list
> changes - the bit between the `(' and `)'. So you need:
>
> always @(clk)
> ....
>
> If you try to synthesise this you will get a latch & not the FFs you
> probably want.
>
>
>
Article: 36328
"dfx2001" <dfx2001@263.net> writes:
> who knows how to detect both edges (rising and falling edge) of clock in
> verilog?
>
> always @(posedge clk or negedge clk)
> counter <= counter + 1; //only count 1, not 2
I don't know verilog, but in VHDL it's certainly easy to write
code that is triggered on both edges. The problem is that it generally
can't be synthesized, because there aren't flip-flops that clock
on both edges. There are kludgey ways to make it work, but it's best
to reformulate the problem so it doesn't require clocking on both
edges.
One approach to what you want is to have two counters, clocked on
opposite edges, and add the outputs.
But if one thinks about the problem a bit, a simpler solution becomes
apparent. If you just count the falling transitions, you will get
half the count you want, but without being able to distinguish whether
there has been a rising transition. If there has not been a rising
transition, the low bit of your desired count is zero. If there has,
the low bit will be one. Thus the value of the input is itself equal
to the least significant bit of your desired count.
For an n-bit count output, you simple use an n-1 bit counter triggered
on the falling edge of the clock:
clock
input
|
+--------------------------------+ |
| (n-1) bit __ | |
| counter \__ clock <|---+
| | |
| Q [n-2] ... Q [0] | |
+--------------------------------+ |
| | |
V V V
count [n-1] ... count [1] count [0]
Article: 36329
In theory yes, but if you have any jitter on the clocks, you may have problems.
Note that you can get substantial clock jitter due to switching I/Os on the same
bank as the clock input, so even with a very stable external clock you can have
problems. Also, widely different loading on the clock networks can induce a
sizable skew between the clocks. A safer tact would be careful use of clock
enables to make sure transitions happen away from the edges where they are
clocked into the opposite domain. (We were bitten by this when the Virtex parts
first came out, so we take care to make safe crossings in our designs now).
Dan Kuechle wrote:
> If I use two DLL's to generate a x4 clock such that the rising edges of the
> x1 and x4 clocks align, and have the x1 and x4 clks on global clocks
> buffers, can I go from one clock domain to the other with just a flip flop?
> In other words, are the rising edges aligned close enough so I don't have to
> worry about metastability and other nasty things?
>
> Dan
--
--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: 36330
khtsoi@cse.cuhk.edu.hk wrote:
> Ray Andraka <ray@andraka.com> wrote:
> > You are apparently traversing two chains in this particular path. The
> > data sheet performance is based on a single carry chain, which you'll see
> That's the real problem. I just don't know how to tell the tools not to
> break the chain (Synopsys Design Compiler & Xilinx Alliance 3.1i).
> Must I use core gen?
The tools shouldn't be breaking the chain, although at 64 bits, it may have to
be broken to fit within the height of your device. For 64 bits, the array has
to be at least 32 CLBs tall to avoid breaking the chain.
>
>
> > as the Topcyf or g to get on, + N-2 * Tbyp for each bit pair in the
> > chain, plus a Tciny or Tcisu for the time to get off the chain. To
> > achieve the data sheet performance, you'll need to use the clb registers
> > on the output in the same slice as the carry chain, AND you'll have to
> > register all the inputs in an adjacent slice with no other loads on the
> > registered inputs.
> Is that mean I cannot drive other devices by the adder outputs directly?
> Then how can I implement i+j+k in one clock cycle?
You can do that by cascading adders, but be aware that you will not reach the
data sheet performance. That is two layers of adders. I think you'll improve
your timing a little by using a carry save layer to reduce the 3 input vectors
to a carry vector and a sum vector, then adding those together in a
conventional adder (a shallow wallace tree). It will still not hit the data
sheet performance, but you'll at least reduce the delay to the adder plus a LUT
in front of it.
>
>
> Anyway, thanks a lot!
>
> ---- Brittle
--
--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: 36331
The macros do not have edif netlists, therefore you either have to produce your
own, or figure out how to generate a netlist for the macro. Use Coregen instead,
as that produces placed edif netlists.
RLOCs are hierarchical. As long as the lowest level has RLOC'd primitives, then
you can put RLOCs on your design components. They work the same way as with the
primitives. Refer to the XIlinx libraries guide for the details.
khtsoi@cse.cuhk.edu.hk wrote:
> khtsoi@cse.cuhk.edu.hk wrote:
> > Hi,
>
> > I have just learnt to use RLOC to place the components closer inside a larger
> > component. But how can I forece these larger components to be closer by RLOC.
> > I mean, the component created by myself will not have RLOC attribute and/or
> > other attributes like the LUT4, FDC, etc. Neigther of them will be a regular
> > block (e.g. not a rectangular box). How to instruct the par tools to place
> > them in certain, fixed place? (Using VHDL only!) Thanks in advance!
>
> > ---- Brittle
> Actually I want to use the ADD8 macro in VirtexE. But the gndbuild tool always
> report error not finding the ADD8 component. It can find something like LUT4
> but no macro can be used. I search the alliance3.1i directory and cannot find
> any NMC file. How to use the macro like ADD8 or must I write it by myself?
>
> ---- Brittle
--
--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: 36332
Dear newsgroup!
I have a question concerning a placement constraint.
If I have the following process:
myProc: process(clock,reset)
type statemachineType (one,two);
variable statemachine statemachineType;
begin
if (reset = '1') then
statemachine := one;
something <= '0';
elsif (rising_edge(clock)) then
case statemachine is
when one =>
something <= '0';
if (signal1 = '1' and signal2 = '0' and signal3 = '1')
then
statemachine := two;
end if;
when two =>
something <= '1';
when others => null;
end case;
end if;
end process;
the if statement will result in a LUT4. I can set placement
constraints for the statemachine variable FFs, but how can I fixate
the location of the lookup table?
I tried to handwire a LUT outside of the process like
myLUT: LUT3 port map (
I0 => signal1,
I1 => signal2,
I3 => signal3,
O => switchState);
and then in the process:
if (switchState = '1') then
statemachine := two;
end if;
This allows to place the LUT, but introduces a new logic stage and
is therefor useless.
Any ideas?
Thanks,
-jc-
Article: 36333If you are using the Insight (Xilinx) PCI core, it should come with all the UCF files (and perhaps guide files) that include the proper placement to meet timing. Also, if you purchased the PCI core from Insight, that may include several hours of support from Insight Design Services, who are the PCI experts. "Kevin Brace" <kevinbraceusenet@hotmail.com> wrote in message news:cc7b0b5f.0111042343.3cade106@posting.google.com... > I will like to know effective is the Floorplanner software that comes > with Xilinx ISE series of software. > The design I am working on is a PCI IP core which Tsu (setup time) has > to be less than 7ns, and Tval (clock to output valid) has to be less > than 11ns. > Currently, the worst Tsu I have is 12.974ns, and the worst Tval I have > is 16.594ns. > I synthesized my design with XST Verilog, and I used only automatic > P&R with user constraints (Pad to Setup = 7ns, Clock to Pad = 11ns). > The software I am currently using is ISE WebPack 4.1. > Is it realistic to expect that I will get Tsu and Tval within 7ns and > 11ns respectively if I use the Floorplanner? > Will reducing fan-out during synthesis help? > If so, what number (default is 100) is appropriate? > Are there any other helpful synthesis/P&R options that will improve > the timings? > The part I am using is Spartan-II 150K system gate part speed grade -5 > which comes with Insight Electronics Spartan-II PCI Development Kit, > so the use of speed grade -6 is not an option. > I already synthesized my design with the speed grade -6, and that > improved the worst timings by 20%, but that still wasn't enough by > about 15%. > I already tried "Pack I/O Registers/Latches into IOBs" in MAP. > If I packed IOBs for input by selecting "For Inputs Only" or "For > Inputs or Outputs", it created a positive hold time, a no-no in PCI > (hold time has to be 0ns in PCI). > Selecting "For Outputs Only" didn't seem to improve Tval that much. > If the Floorplanner is going to help, what kinds of strategies should > I use to hand place the design? > > > > Regards, > > > > Kevin Brace (don't respond to me directly, respond within the > newsgroup)Article: 36334
The logic (the if statement) has to be encoded into the INIT attribute of
the LUT, and then the process reduces to just the flip-flop. If you
instantiate the LUT and the Flip-flop the placement constraints can be put
on them right in the VHDL as RLOCs. Encoding the LUT is awkward, as you
might have guessed, especially if you are starting out with a text
construct like the if-then-else.
If you can keep the combinatorial logic to a single layer, then the mapper
will place that logic with the flip-flop, and you avoid having to place
the LUTs. If the LUT drives the reset or set of and FDR or FDS, or drives
the clock enable, or drives another LUT, then you'll end up with a LUT
that doesn't place with the flip-flop. Unfortunately the placer seems to
do an exceptionally poor job at placing second level LUTs like that.
If you are using synplicity, you can put your lut logic inside a separate
component and put the xc_map attribute on it. That permits you to place
the LUT as well. In that case, you can put the if-then-else logic inside
the separate component.
I try to avoid having to place the LUTs since it is awkward and gives
fairly hard to read code. It is often necessary however.
Jens-Christian Lache wrote:
> Dear newsgroup!
>
> I have a question concerning a placement constraint.
> If I have the following process:
>
> myProc: process(clock,reset)
> type statemachineType (one,two);
> variable statemachine statemachineType;
> begin
> if (reset = '1') then
> statemachine := one;
> something <= '0';
> elsif (rising_edge(clock)) then
> case statemachine is
> when one =>
> something <= '0';
> if (signal1 = '1' and signal2 = '0' and signal3 = '1')
> then
> statemachine := two;
> end if;
> when two =>
> something <= '1';
> when others => null;
> end case;
> end if;
> end process;
>
> the if statement will result in a LUT4. I can set placement
> constraints for the statemachine variable FFs, but how can I fixate
> the location of the lookup table?
>
> I tried to handwire a LUT outside of the process like
>
> myLUT: LUT3 port map (
> I0 => signal1,
> I1 => signal2,
> I3 => signal3,
> O => switchState);
>
> and then in the process:
>
> if (switchState = '1') then
> statemachine := two;
> end if;
>
> This allows to place the LUT, but introduces a new logic stage and
> is therefor useless.
>
> Any ideas?
>
> Thanks,
>
> -jc-
--
--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: 36335duola wrote: > I want use RAM in my Spartan2 chip.When I use the instance of block RAM of > Spartan2 as following: > > module ram(clk,we,din,dout,addr); > input clk,we; > input [7:0]din; > input [8:0]addr; > output [7:0]dout; > RAMB4_S8 > ram0(.WE(we),.EN(1'b0),.RST(1'b0),.WE(we),.ADDR(addr),.DI(din),.DO(dout)); > endmodule > > But synplify gave me an error"Reference to undefined module RAMB4_S8".Does > Synplify support the Spartan2 family?Why does it not recognize the block RAM > of Spartan2? > Who can tell me? > Thank you! > Deerlux White You need to add the Synplify ``Black Box'' stub library to the list of Verilog source files when synthesising. You should find it in: <Synplify_Install_Dir>/synplify/lib/xilinx/<device_family>.v For Spartan2 device_family = virtex.Article: 36336
Someone from Altera got back to me the other day, having seen my original posting. They will be reorganising their download facility, which should resolve the problem. LeonArticle: 36337
Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3BE79170.48636C95@algor.co.uk>...
> Ray Andraka wrote:
>
> > The floorplanner won't help with I/O timing if you have the I/Os
> > registered in the IOB. You should, however check to verify that the
> > registers did go into all the IOBs on your critical path. There are a
> > number of conditions that have to be met for the register to go into the
> > IOB; miss one of them, and the register goes into the core getting you a
> > longer input setup and output clk to Q. Set the output ffs to a faster
> > slew rate, and set the input ones to no delay. Use the DLL to keep the
> > internal clock phase aligned with your external clock (that'll reduce the
> > times). 7 and 11 should be OK with registered I/O in a spartanII-5. You
> > probably won't reach those numbers if you don't use the register in the
> > I/O
> >
> > Kevin Brace wrote:
> >
> >
>
> All Ray's suggestions are correct 'cept the DLL one. Whether or not you can
> use this on the PCI clock depends on whether you are going to follow the PCI
> spec strictly and allow the clock min frequency to be 0. Even if your
> architecture doesn't do PCI clock stopping the DLL imposes a min freq. limit
> (25MHz for V-E ?).
After reading Ray's advise, I tried to attach a DLL macro (the
standard DLL macro inside Xilinx Application Note 174 zip file) to the
clk input of the PCI IP core, but I couldn't get past MAP (got
errors).
But I forgot that in PCI, the clock frequency can be at any frequency
between 0 through 33MHz (in 33MHz PCI), and the application note also
mentioned that it is not recommended to change the clock frequency
when the DLL is being used, so I guess I won't be able to use the DLL.
I am personally going to follow the specification strictly,
even though I know it seems stupid to do so, since even Intel doesn't
follow the specification.
For example, recent Intel chipsets don't support data parity error
checking (they don't have PERR# signal).
Because I am following the specification strictly, I bothered to
implement data parity error checking during target access, which in
practice no one uses or cares.
>
> PCI timing posed a real problem for the PCI i/f I did ~3 years ago in an
> XCV300-4. Tco was not a problem once I'd persuaded Synplify not to mess up
> the IOB packing rules. Tsu was a whole other story since the PCI protocols
> make it very difficult to use registered inputs. With a lot of sweat I
> managed to get Tsu down to ~7.5-8 nsec with the automatic tools. Ray will
> remember that this was in the early Virtex days when Xilinx's attitude was
> ``FloorPlanner? Virtex doesn't need it''.
When I set "Pack I/O Registers/Latches into IOBs", to
"For Inputs Only" or "For Inputs and Outputs", it introduces hold time
on the inputs, which has to be 0ns in PCI.
Setting "Pack I/O Registers/Latches into IOBs", to "For Outputs Only"
or "For Inputs and Outputs", didn't seem to improve Tval (Tco) timings
that much.
Perhaps it is because of clock skew in my design, but can it also be
because I put a multiplexer before a tri-state buffer?
/
goes into {----------------------
PCI Target Sequencer and \ |
Backend Bus |
|
|
|
TRDY_n Select ---------------------------- |
| |
\|/ |
------------ |
\| | |
from PCI Target Sequencer TRDY_n --| | |
(D-FF) /| | | \
| MUX |----- to Tri-State
Buffer
\| | /
from Backend Bus TRDY_n -----------| |
(D-FF) /| |
------------
TRDY_n OE -----------------------
|
|
\ |
| \|/
| \
\| \ \
from MUX --------------------|Tri/------------------- to TRDY_n pin
/| / /
| /
|/
Although the diagram says the diagram is for TRDY_n, things are also
identical for DEVSEL# and STOP#, and output section of AD[31:0]
(AD[31:0] is bidirectional, but input part of it is not shown here).
In my design, initially (first three clock cycles), PCI Target
Sequencer drives AD[31:0], DEVSEL#, TRDY#, and STOP#.
However, after the Backend Bus is ready (from fourth clock cycle), the
Backend Bus drives AD[31:0], DEVSEL#, TRDY#, and STOP#, until the end
of the transaction.
Because I have a requirement that Backend Bus has to take over the
control of the PCI bus, I don't see how I can get rid of the
multiplexer.
Perhaps, if I somehow got rid of the requirement of letting the
Backend Bus control the PCI bus, I can get rid of the multiplexer,
then I will only have a D-FF coming from PCI Target Sequencer into a
tri-state buffer.
My guess is that that's the only situation in which the D-FF can be
included inside the IOB.
>
> On top of this the device had to live in a system where the clock was stepped
> up from 8, 24, 32MHz and used spread spectrum EMI reduction.
>
> I was fortunate in that we were working in a ``closed'' PCI universe with a
> limited range of other PCI masters and a short bus so the 1nsec error didn't
> matter.
>
> I've since figured out a way to use registered inputs (I think) but with
> Virtex-E -6 I don't yet need it for 33MHz PCI.
The only problem I can think of Virtex-E is that it doesn't
support 5V tolerent I/O, so without an external resistor or a logic
level conversion chip (It seems like recent nVidia and ATi PCI
graphics cards put that between the chip and PCI) I cannot plug such a
card into a 5V PCI slot.
In my case setting "Pack I/O Registers/Latches into IOBs", to
"For Inputs Only" or "For Inputs and Outputs" introduce hold time on
the inputs, which has to be 0ns in PCI.
How were you able to avoid having any hold time?
I guess the way I designed my PCI IP core causes the problem.
Just for reference, here is the result I got for Post-P&R report,
followed by P&R report.
One thing I am starting to notice is that, most inputs with Logic
Levels of 4 or less seem to meet Tsu = 7ns, but if it goes to Logic
Levels of 5 or above, it starts to miss Tsu timings.
It seems like (I guess it is sort of common sense) Logic Levels have
direct impact on Tsu.
Another interesting thing I noticed just yesterday is for Map
Properties -> Optimization Strategy, if I select Speed, it gives
result far worst for Tsu (not much change in Tco) than Balanced, Area,
or Off.
Speed: Timing errors: 292 Score: 299067
Balanced: Timing errors: 87 Score: 157911
Area or Off: Timing errors: 127 Score: 162399
I am surprised to see that P&R score differs so much by just one
option selection I make.
I am afraid that the worst Tsu number I mentioned in the initial
posting (worst Tsu = 12.974ns) may have been because I set Map
Properties -> Optimization Strategy to Speed thinking that will give
the best result.
I guess being too aggressive doesn't always pay off.
Regards,
Kevin Brace (don't respond to me directly, respond within the
newsgroup)
***********************************************************************
54 constraints not met.
Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)
Setup/Hold to clock CLK
---------------+------------+------------+
| Setup to | Hold to |
Source Pad | CLK (edge) | CLK (edge) |
---------------+------------+------------+
AD<0> | 7.886(R)| 0.000(R)|
AD<10> | 7.312(R)| 0.000(R)|
AD<11> | 4.227(R)| 0.000(R)|
AD<12> | 5.628(R)| 0.000(R)|
AD<13> | 6.380(R)| 0.000(R)|
AD<14> | 5.961(R)| 0.000(R)|
AD<15> | 6.280(R)| 0.000(R)|
AD<16> | 7.249(R)| 0.000(R)|
AD<17> | 7.098(R)| 0.000(R)|
AD<18> | 7.119(R)| 0.000(R)|
AD<19> | 7.122(R)| 0.000(R)|
AD<1> | 7.999(R)| 0.000(R)|
AD<20> | 7.022(R)| 0.000(R)|
AD<21> | 6.979(R)| 0.000(R)|
AD<22> | 6.675(R)| 0.000(R)|
AD<23> | 6.775(R)| 0.000(R)|
AD<24> | 7.061(R)| 0.000(R)|
AD<25> | 6.621(R)| 0.000(R)|
AD<26> | 6.879(R)| 0.000(R)|
AD<27> | 6.870(R)| 0.000(R)|
AD<28> | 6.633(R)| 0.000(R)|
AD<29> | 6.708(R)| 0.000(R)|
AD<2> | 5.982(R)| 0.000(R)|
AD<30> | 7.127(R)| 0.000(R)|
AD<31> | 7.067(R)| 0.000(R)|
AD<3> | 4.989(R)| 0.000(R)|
AD<4> | 4.718(R)| 0.000(R)|
AD<5> | 5.181(R)| 0.000(R)|
AD<6> | 6.666(R)| 0.000(R)|
AD<7> | 5.465(R)| 0.000(R)|
AD<8> | 7.408(R)| 0.000(R)|
AD<9> | 6.578(R)| 0.000(R)|
C_BE_n<0> | 6.536(R)| 0.000(R)|
C_BE_n<1> | 6.666(R)| 0.000(R)|
C_BE_n<2> | 6.964(R)| 0.000(R)|
C_BE_n<3> | 7.251(R)| 0.000(R)|
FRAME_n | 7.631(R)| 0.000(R)|
IDSEL | 7.670(R)| 0.000(R)|
IRDY_n | 7.671(R)| 0.000(R)|
PAR | 6.006(R)| 0.000(R)|
RST_n | 6.486(R)| 0.000(R)|
---------------+------------+------------+
Clock CLK to Pad
---------------+------------+
| CLK (edge) |
Destination Pad| to PAD |
---------------+------------+
AD<0> | 15.604(R)|
AD<10> | 15.104(R)|
AD<11> | 15.066(R)|
AD<12> | 14.594(R)|
AD<13> | 14.782(R)|
AD<14> | 15.215(R)|
AD<15> | 15.352(R)|
AD<16> | 15.160(R)|
AD<17> | 14.660(R)|
AD<18> | 15.298(R)|
AD<19> | 13.926(R)|
AD<1> | 15.880(R)|
AD<20> | 14.588(R)|
AD<21> | 14.772(R)|
AD<22> | 14.639(R)|
AD<23> | 15.150(R)|
AD<24> | 15.157(R)|
AD<25> | 14.837(R)|
AD<26> | 15.045(R)|
AD<27> | 14.844(R)|
AD<28> | 14.831(R)|
AD<29> | 14.448(R)|
AD<2> | 15.493(R)|
AD<30> | 15.320(R)|
AD<31> | 14.768(R)|
AD<3> | 15.430(R)|
AD<4> | 15.176(R)|
AD<5> | 15.659(R)|
AD<6> | 15.233(R)|
AD<7> | 16.103(R)|
AD<8> | 16.064(R)|
AD<9> | 15.586(R)|
DEVSEL_n | 14.705(R)|
PAR | 12.504(R)|
PERR_n | 12.828(R)|
SERR_n | 12.190(R)|
STOP_n | 14.358(R)|
TRDY_n | 15.560(R)|
---------------+------------+
Clock to Setup on destination clock CLK
---------------+---------+---------+---------+---------+
| Src:Rise| Src:Fall| Src:Rise| Src:Fall|
Source Clock |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall|
---------------+---------+---------+---------+---------+
CLK | 14.051| | | |
---------------+---------+---------+---------+---------+
Timing summary:
---------------
Timing errors: 87 Score: 157911
Constraints cover 6946 paths, 0 nets, and 3159 connections (92.7%
coverage)
Analysis completed Tue Nov 06 14:52:01 2001
--------------------------------------------------------------------------------
***********************************************************************
***********************************************************************
WARNING:Par:62 - Timing constraints have not been met.
Asterisk (*) preceding a constraint indicates it was not met.
--------------------------------------------------------------------------------
Constraint | Requested | Actual
| Logic
| |
| Levels
--------------------------------------------------------------------------------
TS_CLK = PERIOD TIMEGRP "CLK" 30 nS HI | 30.000ns | 14.051ns
| 5
GH 50.000000 % | |
|
--------------------------------------------------------------------------------
COMP "C_BE_n<0>" OFFSET = IN 7 nS BEFORE | 7.000ns | 6.536ns
| 4
COMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "C_BE_n<1>" OFFSET = IN 7 nS BEFORE | 7.000ns | 6.666ns
| 4
COMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "C_BE_n<2>" OFFSET = IN 7 nS BEFORE | 7.000ns | 6.964ns
| 5
COMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "C_BE_n<3>" OFFSET = IN 7 nS BEFORE | 7.000ns | 7.251ns
| 5
COMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "FRAME_n" OFFSET = IN 7 nS BEFORE C | 7.000ns | 7.631ns
| 5
OMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "IDSEL" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 7.670ns
| 5
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "IRDY_n" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 7.671ns
| 5
MP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "RST_n" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 6.486ns
| 2
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<0>" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 7.886ns
| 5
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<0>" OFFSET = OUT 11 nS AFTER CO | 11.000ns | 15.604ns
| 3
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<10>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 7.312ns
| 5
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<10>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 15.104ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<11>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 4.227ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<11>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 15.066ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<12>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 5.628ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<12>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.594ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<13>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 6.380ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<13>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.782ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<14>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 5.961ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<14>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 15.215ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<15>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 6.280ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<15>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 15.352ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<16>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 7.249ns
| 6
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<16>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 15.160ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<17>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 7.098ns
| 6
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<17>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.660ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<18>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 7.119ns
| 6
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<18>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 15.298ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<19>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 7.122ns
| 6
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "ad<19>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 13.926ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<1>" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 7.999ns
| 5
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<1>" OFFSET = OUT 11 nS AFTER CO | 11.000ns | 15.880ns
| 3
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<20>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 7.022ns
| 5
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<20>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.588ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<21>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 6.979ns
| 5
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<21>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.772ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<22>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 6.675ns
| 5
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<22>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.639ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<23>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 6.775ns
| 5
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<23>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 15.150ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<24>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 7.061ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<24>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 15.157ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<25>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 6.621ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<25>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.837ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<26>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 6.879ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<26>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 15.045ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<27>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 6.870ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<27>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.844ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<28>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 6.633ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<28>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.831ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<29>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 6.708ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<29>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.448ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<2>" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 5.982ns
| 3
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<2>" OFFSET = OUT 11 nS AFTER CO | 11.000ns | 15.493ns
| 3
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<30>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 7.127ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<30>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 15.320ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<31>" OFFSET = IN 7 nS BEFORE CO | 7.000ns | 7.067ns
| 4
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<31>" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.768ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<3>" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 4.989ns
| 3
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<3>" OFFSET = OUT 11 nS AFTER CO | 11.000ns | 15.430ns
| 3
MP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<4>" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 4.718ns
| 3
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<4>" OFFSET = OUT 11 nS AFTER CO | 11.000ns | 15.176ns
| 3
MP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<5>" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 5.181ns
| 4
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<5>" OFFSET = OUT 11 nS AFTER CO | 11.000ns | 15.659ns
| 3
MP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<6>" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 6.666ns
| 4
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<6>" OFFSET = OUT 11 nS AFTER CO | 11.000ns | 15.233ns
| 3
MP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<7>" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 5.465ns
| 4
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<7>" OFFSET = OUT 11 nS AFTER CO | 11.000ns | 16.103ns
| 3
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<8>" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 7.408ns
| 4
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<8>" OFFSET = OUT 11 nS AFTER CO | 11.000ns | 16.064ns
| 3
MP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "AD<9>" OFFSET = IN 7 nS BEFORE COM | 7.000ns | 6.578ns
| 4
P "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "AD<9>" OFFSET = OUT 11 nS AFTER CO | 11.000ns | 15.586ns
| 3
MP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "DEVSEL_n" OFFSET = OUT 11 nS AFTER | 11.000ns | 14.705ns
| 3
COMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "INTA_n" OFFSET = OUT 11 nS AFTER C | |
|
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "PAR" OFFSET = IN 7 nS BEFORE COMP | 7.000ns | 6.006ns
| 5
"CLK" | |
|
--------------------------------------------------------------------------------
* COMP "PAR" OFFSET = OUT 11 nS AFTER COMP | 11.000ns | 12.504ns
| 2
"CLK" | |
|
--------------------------------------------------------------------------------
* COMP "PERR_n" OFFSET = OUT 11 nS AFTER C | 11.000ns | 12.828ns
| 2
OMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "SERR_n" OFFSET = OUT 11 nS AFTER C | 11.000ns | 12.190ns
| 2
OMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "STOP_n" OFFSET = OUT 11 nS AFTER C | 11.000ns | 14.358ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
* COMP "TRDY_n" OFFSET = OUT 11 nS AFTER C | 11.000ns | 15.560ns
| 3
OMP "CLK" | |
|
--------------------------------------------------------------------------------
COMP "User_LED" OFFSET = OUT 11 nS AFTER | |
|
COMP "CLK" | |
|
--------------------------------------------------------------------------------
OFFSET = IN 7 nS BEFORE COMP "CLK" | |
|
--------------------------------------------------------------------------------
OFFSET = OUT 11 nS AFTER COMP "CLK" | |
|
--------------------------------------------------------------------------------
54 constraints not met.
Dumping design to file *********.ncd.
All signals are completely routed.
Total REAL time to PAR completion: 30 mins 10 secs
Total CPU time to PAR completion: 30 mins 10 secs
Placement: Completed - No errors found.
Routing: Completed - No errors found.
Timing: Completed - 87 errors found.
PAR done.
***********************************************************************
Article: 36338On 6 Nov 2001 06:42:09 -0800, assaf_sarfati@yahoo.com (Assaf Sarfati) wrote: >Hi everyone, > >I am trying to simulate the gate-level VHDL file generated by Xilinx >P&R tools. My test design is a bunch of counters connected to an >inferred distributed-RAM. The target device is a Virtex-2 chip. > >When I simulate the gate-level VHDL by itself, I get timing violation >warnings (sometimes) when writing to the distributed-RAM; watching the >simulator waveforms, it appears that the clock to the RAM has a 100-pS >phase difference to the counters' clock (the clock is routed as a >global clock net). > >When I add the gate-level SDF file to the simulation, all the timing >violation warnings disappear (for all cases: min, max and typ). > >Trying to trace the generated VHDL code, I see that signals are routed >through buffer entities, with built-in delays; apparently the VHDL >design itself contains all required delays. > >Why would adding the SDF to the simulation make errors _disappear_? >it should be a more thorogh timing-check and find _more_ timing >errors. > >Can anyone explain? There are clock delays built in to the simprim (& unisim) components that are present regardless of whether you use the SDF. These delays can cause hold time problems, and using the SDF will delay the data signals sufficiently to avoid the hold time issues. You can disable these delays in your simulator. (If using Modelsim, try vsim +notimingchecks) Regards, Allan.Article: 36339
In article <cc7b0b5f.0111031727.9ebf9a7@posting.google.com>, kevinbraceusenet@hotmail.com (Kevin Brace) wrote: >I have never used Lattice's devices, so I don't know much about them. >However, regarding PCI, I don't know how things will go with a CPLD, >but at least with an FPGA from my experience trying get my own PCI IP >core to meet timings with Xilinx Spartan-II 150K system gate part, it >is very hard for a synthesizable (HDL-based) PCI IP core to meeting >timings of even 33MHz PCI (Tsu = 7ns and Tval (Tco) = 11ns) with only >automatic Place & Route (in other words, without using a floorplanner >tool). Shouldn't be a problem for me. I virtually never use auto P&R anyway, having discovered long ago that it does a very poor job, at least for the types of designs I tend to integrate. Currently I do the bulk of my design for Virtex directly at the hardware level, using FPGA Editor! >I know that Xilinx and Altera has a PCI IP core that support 66MHz and >64-bit PCI, but it looks like Xilinx has much more devices supported >compared to Altera... Xilinx does seem to have attractive PCI capabilities. In the case of FPGA's it's a no-brainer. I'm not sure about their capabilities in CPLD's however, and I don't think they have a PCI core for CPLD - after all, their biggest CPLD only goes to 288 macrocells. >Some people may be concerned that an SRAM-based FPGA may not program >by the time the BIOS starts executing POST (Power On Self Test) code, >but I am told that an FPGA that can handle PCI can program itself >within 100ms, before RST# (PCI's reset signal) gets asserted to reset >all PCI devices. >POST code will get executed after that. If that were really a big issue with an FPGA, you could use a reconfigurable-logic methodology to load just enough into the FPGA to run basic PCI functionality, then with the system up and stable, run a reconfiguration to add the extra features. .. >One problem with 64-bit 66MHz PCI (3V) is that very few systems >support it compared to ubiquitous 5V 32-bit 33MHz PCI, Which is IMHO a sad state of affairs. Why can so few companies be brave and advance the standards? People won't adopt until somebody takes the lead, and if companies won't take the lead until somebody starts to adopt, you have a nice little vicious cycle to maintain the status quo. As it is, all our PC's in the office have 64-bit Mylex RAID controllers in them anyway, so we're already above the power curve. Part of the reason I want to design for 64-bit PCI is that the standard requires they be downward compatible with 32-bit. That lets us adopt a more forward-thinking technology position for our design without stranding legacy customers. > >arast@inficom.com (Alex Rast) wrote in message > news:<ANEE7.153$FU5.365042@news.uswest.net>... >> Lattice has a core on their site for 32-bit PCI, but I'm wondering if there > is >> available from Lattice or third parties a 64-bit core.... Alex Rast arast@qwest.net arast@inficom.comArticle: 36340
"Kevin Neilson" <kevin_neilson@removethis-yahoo.com> wrote in message news:<FxYF7.57327$IR4.31013561@news1.denver1.co.home.com>...
> If you are using the Insight (Xilinx) PCI core, it should come with all the
> UCF files (and perhaps guide files) that include the proper placement to
> meet timing. Also, if you purchased the PCI core from Insight, that may
> include several hours of support from Insight Design Services, who are the
> PCI experts.
>
Yes, I am using Insight Electronics Spartan-II PCI Development
Kit, but I have the cheapest one ($145, only the PCI card) which
doesn't come with a license for the Xilinx LogiCORE PCI IP core (the
kit with the license costs $2000).
I developed my own PCI IP core in Verilog (not schematics like
supposedly Xilinx did), and that is the reason I am asking about good
strategies on how to floorplan the design because it is not meeting
33MHz PCI's timings.
The PCI IP core worked in two actual computers (one with Intel 430TX
chipset and another one with SiS 5598 chipset) despite the fact that
the design didn't meet timings.
However, I am trying to strictly follow (I know no one does) PCI's
specification, therefore, I can't call the thing done until I can meet
timings.
Regards,
Kevin Brace (don't respond to me directly, respond within the
newsgroup)
Article: 36341Hi all, Are there any good books that have (vhdl) fifo designs and discussion on asynchronous clock domains etc?Article: 36342
Hi, Does anyone have any good suppliers for FPGAs in very small quantities, like 1 or 2? I'm particularly interested in the Xilinx Spartan chips. I just tinker with this stuff as a hobby, so I'm not looking to buy zillions of parts. I've previously been able to get older parts, like the XC52XX. But newer chips seem to be a problem. I can special order something like the XCS10XL-4PC84C from Digikey, but their minimum quantity for this is 30 which is $400 worth of chips, ouch! Yeah, I know Xilinx has a web store, but they only seem to offer CPLDs, which I already have, and can easily purchase. I wish they would offer FPGAs in PLCC packages at least.... I can't be the only tinkerer out there with this problem, so where do you guys get your parts? Cheers, ScottArticle: 36343
We are designing with mentor's HDL author and want to know if there is and easy way to convert/copy the HDL files generated by HDL author and synthesize them in Xilinx's project navigator? Basically, we are getting errors with leonardo when synthesizing code that synthesizes fine in xilinx tools. thanks SWArticle: 36344
"Antonio Pasini" <pasini.a@libero.it> wrote in message news:h9UE7.6714$sq5.364844@news.infostrada.it... > Sorry, I didn't mean to be offensive! English is not my native language; > sure "whining" was not the right term. No need to apologize. I wasn't offended at all. Just wanted to make sure nobody thought I was insane after reading all this stuff about "how it should be". :-) -- -Martin To send private email: 0_0_0_0_@ <delete this part> pacbell.net where "0_0_0_0_" = "martineu"Article: 36345
I think you can still get single quantities from avnet.
http://www.avnetmarshall.com/dynamic/search
"Scott L. Burris" wrote:
> Hi,
>
> Does anyone have any good suppliers for FPGAs in very small
> quantities, like 1 or 2? I'm particularly interested in
> the Xilinx Spartan chips. I just tinker with this stuff
> as a hobby, so I'm not looking to buy zillions of parts.
> I've previously been able to get older parts, like the XC52XX.
> But newer chips seem to be a problem.
>
> I can special order something like the XCS10XL-4PC84C
> from Digikey, but their minimum quantity for this is
> 30 which is $400 worth of chips, ouch!
>
> Yeah, I know Xilinx has a web store, but they only seem
> to offer CPLDs, which I already have, and can easily purchase.
> I wish they would offer FPGAs in PLCC packages at least....
>
> I can't be the only tinkerer out there with this problem,
> so where do you guys get your parts?
>
> Cheers,
>
> Scott
--
--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: 36346I want use RAM in my Spartan2 chip.When I use the instance of block RAM of Spartan2 as following: module ram(clk,we,din,dout,addr); input clk,we; input [7:0]din; input [8:0]addr; output [7:0]dout; RAMB4_S8 ram0(.WE(we),.EN(1'b0),.RST(1'b0),.WE(we),.ADDR(addr),.DI(din),.DO(dout)); endmodule But synplify gave me an error"Reference to undefined module RAMB4_S8".Does Synplify support the Spartan2 family?Why does it not recognize the block RAM of Spartan2? Who can tell me? Thank you! Deerlux WhiteArticle: 36347
Are there any fpga's containing high capacity dram's on chip ? There seem to be quite a few people interfacing to external drams.Article: 36348
With this encoder if i set an input count_in , I've the right output
named count_out only on the next edge of the clock, this is no good
for my project, why this happen and how I can modify this encoder to
have the rigth output directly on the same clock edge ???
Thanks
Banana
library ieee ;
use ieee.std_logic_1164.all ;
entity encoder is
port (
count_in : in std_logic_vector(2 downto 0) ;
reset : in std_logic ;
clk : in std_logic ;
count_out : out std_logic_vector(2 downto 0)
) ;
end encoder ;
architecture encoder_arch of encoder is
begin
process(clk, reset , count_in)
begin
if ( reset = '1') then
count_out <= "XXX";
elsif rising_edge(clk) then
case count_in is
when "001" => count_out <= "000";
when "010" => count_out <= "001";
when "100" => count_out <= "010";
when others => NULL;
end case;
end if;
end process;
end encoder_arch ;
Article: 36349Scott L. Burris <scott@slb.org> wrote: : Hi, : Does anyone have any good suppliers for FPGAs in very small : quantities, like 1 or 2? I'm particularly interested in : ... Quicklogic offers their programmed WebAsics for free... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
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