Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 35700

Article: 35700
Subject: Re: How to instantiate I/O port with both registered input and output?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 14 Oct 2001 08:34:53 +0100
Links: << >>  << T >>  << A >>


Tim wrote:

> Pack flops into IOBs via switches to the mapper.  From memory
> it is something like '-pr b'.  Run map with no arguments to get
> the switch list.
>
> Virtex designs use regular flops in the IOBs, unlike 4K, etc., which
> had magic IFD/OFD flops.
>
> "Marko" <cantsay@here.com> wrote in message
> news:3bc9bc39.59939438@dfiatx1-snr1.gtei.net...
> > I am targeting Xilinx Virtex II with Verilog in an ISE4.1i
> > environment.  I want to instantiate (or infer) a single IOB which has
> > I/O capability, registered output, tristate output control, and
> > registered input.  Both registers can use the same clock.
> >
> > I expected to find a design element in Xilinx's Library Guide, but
> > there is none.
> >
> > All of my attempts so far result in one or both registers being moved
> > out of the IOB into a CLB.  This won't work with my speed
> > requirements.
> >
> > TIA
> > mchampion@Xbigfoot.com (remove the X to send me email)

Its also possible to use the UCF constraint:

INST "your_ff" IOB = <TRUE | FALSE>;

which has priority over the MAP flag. Useful if e.g. you have 2 FFs sourced
from a pin but you only want one of them in the IOB.

There are also these constraints to IOB FF packing (more important if the
FFs are being inferred by synthesis):

o No logic after an output FF, not even an inversion.

o No logic before an input FF, ditto.

o No feedback from an output FF to the reset of the logic. [synthesis
optimisation can do this behind your back if you're not careful].

o If you want to pack both an input and an output FF then they must share a
common initialisation signal. The 2 FFs can independently use this as a
sync/async, set/reset. Note that this implies that you cannot have one FF
with initialisation and the other without it.


Article: 35701
Subject: Re: how do I avoid glitches in this design?
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Sun, 14 Oct 2001 16:51:29 +0200
Links: << >>  << T >>  << A >>
Johan Ditmar schrieb:
> 
> I implement two rotating shift registers (A and B) of three bits wide, one
> that is sensitive to the positive clock edge and one on the negative. I
> initialise one with the even bits of the pulse train ("101") and one with
> the odd ("010") and I let them run on the incoming clock.

Why do you want to use both clock edges? Cant you use a double frequency
clock signal?

> glitch free? As the output changes on both positive and negative clock edge,

Hmm, Iam no glitch expert. But AFAIK a decoder output (I your case the
2:1 MUX of the two shift registers) is always garantied to be glitch
free, IF only 1 input bit is changeing at a time (principle of gray
code). But on your mux, the select input AND one data input can change
on an clock egde so . . . .
Maybe you have to drop the MUX and try to feed the shift registers with
some kind of gray code which will be ORed.

-- 
MFG
Falk



Article: 35702
Subject: Re: High level synthesis will never work well :)
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Sun, 14 Oct 2001 17:05:23 +0200
Links: << >>  << T >>  << A >>
Andy Peters schrieb:
> 
> Falk Brunner wrote:
> 
> > I mean, when the "Hello World" takes 100 Kb in C++, THIS IS REALLY CRAP.
> 
> Aw, c'mon.  You're talking about what happens when you use Visual C++ to
> write a WINDOWS version of "Hello, World."

Ahhh, yes ;-)
 
> Write a short hello.cpp for your linux box, that runs on the command
> line, and tell me how big it is.

I aint got linux, yet ;-)
But using TurboPascal, it takes 4k.

-- 
MFG
Falk


Article: 35703
Subject: Re: FPGA Asynchronous Design
From: Ray Andraka <ray@andraka.com>
Date: Sun, 14 Oct 2001 15:41:29 GMT
Links: << >>  << T >>  << A >>
my point exactly.  It can be done, but is it really worth the price?

Phil Short wrote:

> Ray Andraka wrote:
> >
> > For these reasons, the self timed stuff to date has been for much
> > smaller designs than those commonly done with synchronous logic.
> >
> Seems like a lot of work if you have to battle with your tools the
> whole way.  I guess you have to really be determined to implement
> a self-timed design in a Xilinx FPGA.
>
> --
>
> Phil

--
--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: 35704
Subject: Re: Instantiating Virtex II library macros.
From: Ray Andraka <ray@andraka.com>
Date: Sun, 14 Oct 2001 15:44:32 GMT
Links: << >>  << T >>  << A >>


hamish@cloud.net.au wrote:

> In my experience, you can't instantiate Xilinx macros in your
> HDL code. Ngdbuild doesn't know anything about them (only
> primitives).
>

You can, but the edif files for any macros you use have to be found by
ngdbuild.


--
--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: 35705
Subject: Re: how do I avoid glitches in this design?
From: Bob Perlman <bob@cambriandesign.com>
Date: Sun, 14 Oct 2001 17:29:34 GMT
Links: << >>  << T >>  << A >>
Hi - 

Another approach is to XOR the outputs of the two shift registers.

If the desired output is 100110, then create two 6-bit shift registers
(we'll see why 3-bit registers won't work in just a moment).  The
first register, clocked on the rising edge, is *synchronously*
initialized with the following contents:

MSB  -> 1 1 1 0 0 0 <- LSB

The second register, clocked on the falling edge,  is synchronously
initialized with:

MSB -> 0 1 0 1 0 1 <- LSB

The two MSBs are XORed to produce the output.  

rising edge 1:  reg 1 out = 1, reg 2 out = 0, XOR = 1
falling edge 1: reg 1 out = 1, reg 2 out = 1, XOR = 0
rising edge 2:  reg 1 out = 1, reg 2 out = 1, XOR = 0
falling edge 2: reg 1 out = 1, reg 2 out = 0, XOR = 1
rising edge 3:  reg 1 out = 1, reg 2 out = 0, XOR = 1
falling edge 3: reg 1 out = 1, reg 2 out = 1, XOR = 0
rising edge 4:  reg 1 out = 0, reg 2 out = 1, XOR = 1
falling edge 4: reg 1 out = 0, reg 2 out = 0, XOR = 0
rising edge 5:  reg 1 out = 0, reg 2 out = 0, XOR = 0
falling edge 5: reg 1 out = 0, reg 2 out = 1, XOR = 1
rising edge 6:  reg 1 out = 0, reg 2 out = 1, XOR = 1
falling edge 6: reg 1 out = 0, reg 2 out = 0, XOR = 0
  
Since only one XOR input changes at a time, we get no glitches. (This
assumes that your XOR is glitchless for transitions on a single input,
which it will be if you build it with a Xilinx LUT or even a
straightforward sum of products structure.  But I'm sure someone
possesses the technology to make a glitchy XOR.)

Note that the register patterns need 6 clocks to repeat, hence the
need for double-length registers.

Bob Perlman
Cambrian Design Works

On Fri, 12 Oct 2001 23:33:07 +0100, "Johan Ditmar"
<johan.ditmar@nospamceloxica.com> wrote:

>Hello there,
>
>The past few days I have been trying to come up with a way to describe a
>generic pulse generator in Verilog (or VHDL) using shift registers. What I
>would like it to do is to take an arbitrary pulsetrain as a parameter (for
>example "100110") and then generate this pulse train repeatedly from an
>incoming clock signal. However, each bit in the pulse train corresponds to
>half an incoming clockcycle! I came up with the following scheme to do this:
>
>I implement two rotating shift registers (A and B) of three bits wide, one
>that is sensitive to the positive clock edge and one on the negative. I
>initialise one with the even bits of the pulse train ("101") and one with
>the odd ("010") and I let them run on the incoming clock.
>
>Then I generate a signal from the incoming clock, which simply follows this
>clock (using two flip flops, one positive and one negative edge sensitive),
>and I use this signal to either choose the output of shift register A or
>shift register B and this is then the output of the whole circuit.
>
>However, the output of this circuit is going to be used as a clock which
>feeds other circuits, so it should be glitch free. This is not always the
>case in my present design (I think). Is there some way to make my design
>glitch free? As the output changes on both positive and negative clock edge,
>I canīt put a simple register on the output :-( And I prefer not to use
>PLLīs or DLLīs (which may be used to generate the double clock frequency to
>make everything sensitive to the positive clock edge only).
>
>Any help is greatly appreciated!
>
>Regards,
>
>Johan Ditmar
>
>


Article: 35706
Subject: Re: I need free PCI-Core (vhdl)!!
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: 14 Oct 2001 20:07:56 GMT
Links: << >>  << T >>  << A >>
Ras Sim <simsek@rhrk.uni-kl.de> wrote:
: Hi folks!
: I'm a student and i need a free PCI-Core wich is written in vhdl.
: Where could I download it ?

Not a free HVDL PCI-Core, but a free FPGA with a PCI Interface:
Look at Quicklogics WebAsic Program and there PCI Series.

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 35707
Subject: Re: future Xilinx products wish list ...
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Mon, 15 Oct 2001 01:26:44 +0100
Links: << >>  << T >>  << A >>
"Eric" <erv_NOS_PAM@sympatico.ca> wrote

> Tim wrote:
>
> > I disagree on the dual-use of pins.
>
> Could you explain why you disagree ?
> What kind of problem would it create for your app ?

Banking.  With fast I/Os you pretty much have to take a strategic
view when you allocate the I/Os, and thus the bank standards.  If some
of the banks (two for Virtex-II) are restricted to 3.3V, or whatever,
this sure limits your options and/or complicates your work.

I don't want to go overboard on this.  Most of the config pins are
used 'input-only', but Busy/Dout is OD/output and Init is OD.  SelectMAP
readback uses D0..7 bidirectionally.  The official line is that VCCO
should be flipped to 3.3V for all output-mode configuration pins, though
probably the transistors would not tell anyone if we disobeyed, provided
we made sure that the receivers were compatible.  (The Virtex-II data book
spells this out in more detail.)

Usual form when bringing up a new board is to decide that the darned
thing is _never_ going to configure.  Anything to remove an engineering
doubt...

<snip>

> Maybe all the pins that are already dual use would do better if they were
> grouped on a single or a separate bank. However, I don't see where the
> problem is for you since you seem to to configuration through JTAG and
> you don't use these pin's alternate function.

Nope.  I have never tried JTAG.  My usual practice is to arrange the card
so that I can do an initial bring-up in slave-serial mode - cannot beat
looking at the stream on DOUT :)  Usually that is that, but sometimes the
client wants to move to the faster SelectMap.  So far, nobody has asked for
JTAG config.  But our work is probably not representative of civilized
usage.


> > Maybe the long term plan is to configure/readback the big stuff
> > via JTAG only -
>
> It's not because you don't use other configuration methods that they're
> useless.


Yep, I guess I wasn't too clear.  Here is the problem:  Current (!) V-II
parts need up to 32Mbits of config data.  Click forwards a few generations
and we are going North from 1Gbit.  Handling this at speed cannot readily
be done by extrapolating from JTAG, essentially a system designed by IBM
in 1975.  But it is also relatively difficult in system terms with
SelectMap and its friends.

I was speculating that the configuration interface will evolve to 'JTAG',
if that is fast enough for you, plus 'NewTAG'.  NewTAG will be a fast/smart
serial link, possibly serviced at the other end by a boring old Virtex-II.

Now all I need is for someone with his/her finger on the pulse to tell me
that this is all being considered by IEEE Working Group 666 :)






Article: 35708
(removed)


Article: 35709
Subject: PLLs & DLLs
From: gautam_awasthi@yahoo.co.in (Gautam)
Date: 14 Oct 2001 21:20:21 -0700
Links: << >>  << T >>  << A >>
From a FPGA User Perspective, How does Altera PLL differ from Xilinx DLL?

Article: 35710
Subject: Re: Linux tools
From: "James C. Schwalbe" <schwalbe@compuserve.com>
Date: Mon, 15 Oct 2001 02:36:07 -0400
Links: << >>  << T >>  << A >>
Altera will begin supporting the Linux operating system next year.

Jim Schwalbe
Sr. Field Apps Eng
Altera Corp.
jschwalb@altera.com

"Rene Tschaggelar" <tschaggelar@dplanet.ch> wrote in message
news:3BBC6DAA.B11075E6@dplanet.ch...
> When I look at the rather complicated procedure concerning
> MaxPlus2 of Altera, which only runs 3 month, I doubt it.
> The commercial version requires a dongle.
>
> Rene
> --
> Ing.Buero R.Tschaggelar - http://www.ibrtses.com
>
> Zoltan Kocsi wrote:
> >
> > I was away for a while from the NG, is there any word on FPGA
> > vendors offering (or planning to) Linux toolchains (in the same
> > config and pricing as their Win tools) ?
> >
> > Thanks,
> >
> > Zoltan
> >
> > --
> > +------------------------------------------------------------------+
> > | ** To reach me write to zoltan in the domain of bendor com au ** |
> > +--------------------------------+---------------------------------+
> > | Zoltan Kocsi                   |   I don't believe in miracles   |
> > | Bendor Research Pty. Ltd.      |   but I rely on them.           |
> > +--------------------------------+---------------------------------+



Article: 35711
Subject: Re: PLLs & DLLs
From: Falk <>
Date: Mon, 15 Oct 2001 01:47:05 -0700
Links: << >>  << T >>  << A >>
The PLL in the ALTERA ICs is a (P)hase locked loop, which uses a VCO to generate the output signal. A PLL can do clock rate conversion with (almost) any arbitrary conversion factor, where the DLL (D)elay locked loop in the Xilinx devices can only divide by 1.5,2,2.5,3,4,5,8,16 and double the input frequency. But the most important use of a DLL is deskewing of clock signals. This can also be done with PLLs (in the Altera parts) There are some "comparisons" papers from both companys which are trying to proofe the advantages DLLs/PLLs. I dont know at all, how realistic these measurements are and how much marketing-science is involved ;-)

Regards
Falk

Article: 35712
Subject: Re: Timing constraints for unrelated clocks?
From: "fred" <x@y.z>
Date: Mon, 15 Oct 2001 10:14:47 +0100
Links: << >>  << T >>  << A >>

Leo Breuss <lbreuss-nospam@scs.ch> wrote in message
news:3BC6EB89.D6322711@scs.ch...
> Thank you, Fred.
>
> There is a thing I have to add. In case1, in my VHDL code it says
>   Clk2 <= not Clk1;  -- period 8 ns, duty cycle 50%
> So the tools do know exactly about the relation of Clk2 and Clk1. They
> will know, that from rising edge Clk1 to rising edge Clk2 there are only
> 4 ns (positive duty cycle of Clk1)! This will very likely generate
> errors, when the tools are not able to satisfy a path delay Reg1_out to
> Reg3_in of less than 4 ns.
>
> How do I specify constraints for the tools or guide the tools to avoid
> Reg3_in changing state in the setup/hold window of Reg3 or violating its
> setup/hold time? Is there a MINDELAY constraint, if I accept that
> Reg1_out arrives at Reg3_in shortly after rising edge of Clk2?
>
Sorry Leo, I did not see your clk edge defifnition.

IIRC, conventional constraints apply rising to rising edge (and so will also
meet falling to falling) but not guarantee rise to fall or fall to rise. To
do this create a time group rising and a time group falling using the
syntax:
TIMEGRP RFFS = RISING FFS ("*");  // creates a rising group called RFFS
TIMEGRP FFFS = FALLING FFS ("*");  // creates a falling group called FFFS
(these are a global assignment to all flip flops)
then constrain using:
TIMESPEC TS_fall_2_rise = FROM : FFFS : TO : RFFS : 4 ns ;
Beware though, because although I have used this sucessfully in the past,
when I used it again recently, the log file reported that there were no nets
in the group - strange. I worked round it rather than spend time checking it
out.

This info is direct from the sample user constraints file which is created
when ever a foundation project is created - it has extensive examples of
this type - it should exist in you roject directory and be called
<projectname>.ucf

Although I think this answers your question, I have doubts about your
implementation in this case. 125MHz (8ns) is fast enough without opposite
edging the clock. Also I have guessed that your clk1 is being multiplexed
somewhere which will result in clock skew which is not accounted for by the
above constraint scheme. Maybe it would be better to treat even the the
inverse clock as a totally asynchrous one and synchronise the enable to the
clk2 domain before applying it to the mux chain using 2 regs as per Mikes
suggestion. This will mean, of course that you will not have cycle by cycle
muxing capability but I don't think the original could reliably perform that
task either.

Regards,

Fred
ps: More at http://support.xilinx.com - Advanced Search untick answers
database (only) keywords: constraints and timing and UCF



Article: 35713
Subject: Re: future Xilinx products wish list ...
From: "Andrew Brown" <andrewbr@nortelnetworks.com>
Date: Mon, 15 Oct 2001 10:27:09 +0100
Links: << >>  << T >>  << A >>

<hamish@cloud.net.au> wrote in message
news:B2by7.1874$bE1.12165@news1.rdc1.nsw.optushome.com.au...
> Tim <tim@rockylogic.com.nospam.com> wrote:
> > I guess.  For the XC2V10000 the times work out as
> >  JTAG         1000ms  (33MHz, 1-bit)
> >  Slave Serial  500ms  (66MHz, 1-bit)
> >  SelectMap      60ms  (66MHz, 8-bit)


The JTAG rate of 1 sec for 10000 gates seems okay, but the devices are rated
to operate at 10M.
Perhaps they could improve (why is it so slow?)



Article: 35714
Subject: Improving timing
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Mon, 15 Oct 2001 11:56:32 +0200
Links: << >>  << T >>  << A >>
Hi,

Wondering if anyone can give me any tips on improving my timing. I am
reading in 4 bit data into IFD's (inputs and outputs are registered, Pad to
Setup = 2ns). This is accumulated, after passing through a number of things,
and outputted as a 20bit number. (goes from a registered latch, to OFDs to
output pads). My problem is that before I included the 20bit output, I had a
6bit test output with Clock to Pad constraint of 3.4ns, which the PAR
achieved quite easily. I then included the 20bit, again with the Clock to
Pad constraint of 3.4ns, and the PAR can neither achieve this for both the
20bit output and the 6bit test output, with net delays of 5ns. Is there
anyway to improve this? Why the degradation of the 6bit output? The design
runs at 32MHz on a Spartan II.

thanks
adrian




Article: 35715
Subject: Re: future Xilinx products wish list ...
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Mon, 15 Oct 2001 11:51:42 +0100
Links: << >>  << T >>  << A >>

"Andrew Brown" <andrewbr@nortelnetworks.com> wrote
>
> > >       For the XC2V10000 the times work out as
> > >  JTAG         1000ms  (33MHz, 1-bit)
> > >  Slave Serial  500ms  (66MHz, 1-bit)
> > >  SelectMap      60ms  (66MHz, 8-bit)
>
>
> The JTAG rate of 1 sec for 10000 gates seems okay, but the devices are rated
> to operate at 10M.
> Perhaps they could improve (why is it so slow?)

XC2V10000 is 10M (marketing) gates with 32M config bits.  At 33MHz this
takes approx 1 second.  So slow because 33MHz is slow.  But it is only
a few years since 33MHz was rather fast :)






Article: 35716
Subject: Spartan2: opposite of Synch-to-DONE?
From: "Hayden So" <haydenso@yahoo.com>
Date: Mon, 15 Oct 2001 04:04:44 -0700
Links: << >>  << T >>  << A >>
Hi All,

I have two Spartan2 on my board with their respective DONE pin tied together, pulled-up and connected to a LED.  The LED is supposed to light up when both of the FPGA are configured.

During testing phase, the 2 FPGAs are configured using JTAG.  Both of them configured, LED lights, and work just fine.

However, here's the problem when I am trying to move away from the JTAG cable: When I was configuring the 2 with JTAG, even after the first (FPGA1) is configured, JTAG programmer complains it can't verify DONE goes high.  Sure enough, DONE is still "low", because my 2nd FPGA is not configured.  But the real problem is FPGA1 does not start running until *AFTER* FPGA2 is configured and releases its DONE pin.

So here is my question: (1) does anyone know if a Spartan2 sample the value of its DONE pin before it starts functioning (startup sequence)?  (2) If so, is there a way I can get away with it? (some setting in the bitstream maybe?)

From Xilinx datasheet, it mentioned how one can do a "Synch-to-DONE" startup.  That is great but what I want is EXACTLY the opposite.  I want FPGA1 to be up and running *before* FPGA2 starts.  And sure enough, my bitstream used just the default startup sequence with no event depends on DONE.  I can't figure out why would FPGA1 waits for the DONE pin to goes high.  The configuration flowchart in Xilinx datasheet didn't mention sampling of DONE at the end...

Any help would be greatly appreciated.

Hayden So

Article: 35717
Subject: Re: Improving timing
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 15 Oct 2001 12:33:46 +0100
Links: << >>  << T >>  << A >>


Noddy wrote:

> Hi,
>
> Wondering if anyone can give me any tips on improving my timing. I am
> reading in 4 bit data into IFD's (inputs and outputs are registered, Pad to
> Setup = 2ns). This is accumulated, after passing through a number of things,
> and outputted as a 20bit number. (goes from a registered latch, to OFDs to
> output pads). My problem is that before I included the 20bit output, I had a
> 6bit test output with Clock to Pad constraint of 3.4ns, which the PAR
> achieved quite easily. I then included the 20bit, again with the Clock to
> Pad constraint of 3.4ns, and the PAR can neither achieve this for both the
> 20bit output and the 6bit test output, with net delays of 5ns. Is there
> anyway to improve this? Why the degradation of the 6bit output? The design
> runs at 32MHz on a Spartan II.
>
> thanks
> adrian

It sounds like in the first case the output FFs were being mapped into the IOBs
but when you added the 20-bit output they weren't.  Could you be in the
situation now where both the test output and the LS 6 bits of the real output
are being driven from the same FFs ? i.e. a victim of over-enthusiastic
optimisation by the synth/P&R tool(s).


Article: 35718
Subject: Re: Problem about Leonardo Spectrum with Altera MaxPlus II
From: "Wolfgang Loewer" <wolfgang.loewer@elca.de>
Date: Mon, 15 Oct 2001 15:03:35 +0200
Links: << >>  << T >>  << A >>
Hi,

open the compiler and go to "Interfaces", "EDIF Netlist Reader Settings".
For the vendor choose Mentor Graphics or Leonardo Spectrum. You may also
want check the customize button.

Best Regards
Wolfgang
http://www.elca.de

"Huang Qiang" <jameshq@liv.ac.uk> schrieb im Newsbeitrag
news:9q6jgn$t79$1@news.liv.ac.uk...
> Hi all:
>     I have tried to compile the VHDL file in Leonardo spectrum and
generate
> a *.edf file and import into the Altera maxplus II and compile it create a
> default symbol. every step worked without problem. But when I use the
symbol
> in the graphic design and try to compile it I encounter the following
> problem:
>
> Warning " I/O error can't open file *.lmf "
> Error "Can't find design file 'dffe' "
>
> I can't find any setting the *.lmf (library mapping) setting in Altera
> MaxPlus II (PC version).
> Could anybody help me? Thank you very much!
>
> best regards!
>
> email: jameshq@liv.ac.uk
>
>



Article: 35719
Subject: Re: Synplicity/Leonardo License Agreement Information
From: Ken McElvain <ken@synplicity.com>
Date: Mon, 15 Oct 2001 07:57:54 -0700
Links: << >>  << T >>  << A >>


Brian Davis wrote:

> Andy Peters <andy@exponentmedia.deletethis.com> wrote:
> 
>>Uh oh!  The person who posted Synplify's results for that 56-bit counter
>>problem is in line for an ass-whooping!
>>
>>-a
>>
> 
> Andy,
> 
>  They haven't remotely detonated my key ( or my ass ) yet :)
> 
>  According to the Synplify license ( excerpt copyright Synplicity ):
> 
>   "Licensee acknowledges that the scope of the licenses granted
>    hereunder do not permit Licensee (and Licensee shall not allow
>    any third party) to:"
> <snip>
>    "(iv) disclose the results of any benchmarking of the SOFTWARE,
>    or use such results for its own competing software development
>    activities, without the prior written permission of Synplicity;"
> 
>  Personally, I wouldn't consider answering a question on how to make
> a counter synthesize better to be a "benchmark"... 


We don't consider it to be a "benchmark" either.


> 
>   But then again, nor would I make the software guys writing the 
> synthesis tool insert a copyright message into any cuts and pastes
> done from the online help code examples...


I think someone just set the "Copyright" field during the help file
build not knowing what it did.  I'll forward this to our documentation
folks.


> 
> Brian
> 
> p.s. : upon further reflection, perhaps I should have checked to see if
>  posting an excerpt of the license terms is a violation of the license...
> 


Article: 35720
Subject: JTAG-Programmer Linux
From: Marc Reinert <reinert@tu-harburg.de>
Date: Mon, 15 Oct 2001 17:06:17 +0200
Links: << >>  << T >>  << A >>
Is there any good JTAG-Programmer that I can use under Linux to program
Xilinx FPGAs and PROMs over the Parallel III Cable?

I thought the Xilinx JTAG-Programmer is free, but I didn't find a place
to download it in a linux version.

Any good ideas?

Regards

Marc



Article: 35721
Subject: Re: Synplicity/Leonardo License Agreement Information
From: Ken McElvain <ken@synplicity.com>
Date: Mon, 15 Oct 2001 08:06:25 -0700
Links: << >>  << T >>  << A >>


Brian Davis wrote:

> From the Webpack XST license ( excerpt copyright Xilinx ):
> 
>    "2. Restrictions."
>  <snip> 
>     "You may not publish any data or information that compares 
>     the performance of the Software with software created or 
>     distributed by others."
> 
> 
>  ( Had I posted both license excerpts in the same message, would
> that constitute 'license benchmarking' ? )
> 
> ----------------------------------------------------------------
> 
> 
>>Uh oh!  The person who posted Synplify's results for that 56-bit
>>counter problem is in line for an ass-whooping!
>>
> 
>   Upon even more reflection, should it come to that, I could
> probably plead insanity vis-a-vis my original counter post:
> 
>   JUDGE: How do you explain this egregious posting of useful
>    information?
> 
>   DEFENDANT: But your Honor, after reading 3000 responses about
>    asynchronous resets and GSR, none of which clarified the cause
>    of the coherently cleared counter curiously containing copious 
>    CLBs, I just HAD to post a message explaining the paradoxical 
>    result that lowering the synthesis target frequency would result
>    in a counter that is both smaller and faster after P&R.


If the load control and data for a sync load are less critical (before
P&R) than other input signals to the counter, then we build them into 
the carry chain luts.  Otherwise, they get their own column following
the carry chain.  Synplify should have used the sync reset instead
of building a sync load.


> 
>   JUDGE: For your offense, and in the light of your excessive
>    alliteration of words beginning with the letter "C", I hereby 
>    sentence you to use FPGA Express for all future synthesis work. 
>    Bailiff, take him away.
> 
> 
> Brian
> 


Article: 35722
Subject: Re: future Xilinx products wish list ...
From: Eric <erv_NoS_pam@sympatico.ca>
Date: Mon, 15 Oct 2001 11:33:05 -0400
Links: << >>  << T >>  << A >>
Hi,

Tim wrote:

> "Eric" <erv_NOS_PAM@sympatico.ca> wrote
>
> > Tim wrote:
> >
> > > I disagree on the dual-use of pins.
> >
> > Could you explain why you disagree ?
> > What kind of problem would it create for your app ?
>
> Banking.  With fast I/Os you pretty much have to take a strategic
> view when you allocate the I/Os, and thus the bank standards.  If some
> of the banks (two for Virtex-II) are restricted to 3.3V, or whatever,
> this sure limits your options and/or complicates your work.
>

If I get you well, when configuring in bit serial, the annoyance is that D0,
Dout and Init_B being part of Bank 4, they force you to use 3.3V on the
other IOs of that bank. Using SelectMap does the same for bank 5 (if you
don't use SelectMap, bank 5 is unrestricted).

A better way would be to have a specific bank that contains all dual use pins
that are mandatory for all configuration modes (D0, Dout, Prog_B, Init_B,
Done, M0..2, HSwap_En, TCK, TDI, TDO, TMS).
As they are now, except D0 and Dout, they can't be used as IO at all.
Allowing dual use and placing them in a common (voltage restricted if needed)
bank would free Bank 4 in all apps, and provide up to 11 additional IOs in the
same package.

CS_B, RdWr_B, D1..D7 being optional, they can be put in another bank where
their dual use nature would go undetected when SelectMap is not used.

Same would be true for configuration address pins A0 .. An, should they be
added as an option.


> <snip>
>
> > > Maybe the long term plan is to configure/readback the big stuff
> > > via JTAG only -
> >
> > It's not because you don't use other configuration methods that they're
> > useless.
>
> Yep, I guess I wasn't too clear.  Here is the problem:  Current (!) V-II
> parts need up to 32Mbits of config data.  Click forwards a few generations
> and we are going North from 1Gbit.  Handling this at speed cannot readily
> be done by extrapolating from JTAG, essentially a system designed by IBM
> in 1975.  But it is also relatively difficult in system terms with
> SelectMap and its friends.
>
> I was speculating that the configuration interface will evolve to 'JTAG',
> if that is fast enough for you, plus 'NewTAG'.  NewTAG will be a fast/smart
> serial link, possibly serviced at the other end by a boring old Virtex-II.
>

Sure, 33 Mhz JTAG is slow for 32 MB devices and  won't cut it for future 1Gb+
FPGAs, but then a speed doubled & DDR version of SelectMap (133 Mhz x 2 )
would configure a hypothetical 1Gbit FPGA in less than 500 ms. Not that bad !

Very high speed serial could also be added whenever it will be needed, my point
was that the more config modes you have, the easiest it's to integrate a FPGA
in a broad range of devices and having as many dual use pins as possible reduces
the number of pins that are useless (or not used by some) once the device is
configured.
Granted, these are not too important for high end devices that cost 4000+$ and
come in FF1517 package, but at the low end (where the volume applications are)
these details really make a difference.

At all times, care should be taken so that whenever a mode is not used, it does not
interfere with user IO usage.

>
> Now all I need is for someone with his/her finger on the pulse to tell me
> that this is all being considered by IEEE Working Group 666 :)

When there's a will, there's a way ...

regards,

Eric.



Article: 35723
Subject: Re: Timing constraints for unrelated clocks?
From: Leo Breuss <lbreuss-nospam@scs.ch>
Date: Mon, 15 Oct 2001 17:57:08 +0200
Links: << >>  << T >>  << A >>
Thank you, Fred.

> TIMEGRP RFFS = RISING FFS ("*");  // creates a rising group called RFFS
> TIMEGRP FFFS = FALLING FFS ("*");  // creates a falling group called FFFS
> (these are a global assignment to all flip flops)
> then constrain using:
> TIMESPEC TS_fall_2_rise = FROM : FFFS : TO : RFFS : 4 ns ;

But: the path from Reg1 to Reg3 has even more delay than 4 ns. It should be
allowed to take 8ns.
I think your solution works.

I have to try an even more elegant and precise idea:
TIMESPEC "TS_Sel_path" = FROM FFS(Reg1*) 8.000;

this sets on all pathes originating at FFs Reg1* a TIMESPEC of 8 ns.
Do you think this could work? (I do not care if setup/hold of Reg3 is violated)

> Although I think this answers your question, I have doubts about your
> implementation in this case. 125MHz (8ns) is fast enough without opposite
> edging the clock. 

(The schematic I have shown is only the falling edge path of data and an
independent block generating the Select signal. There is also a rising edge data
path (inverted Clk2), which is served by the same Select signal MUX_Sel from
Reg1 (not drawn). The clocks Clk1 and Clk2 are not necessarily synchronous, but
if they are, then it is Clk2 <= not Clk1 for the schematic.)

> Maybe it would be better to treat even the the
> inverse clock as a totally asynchrous one and synchronise the enable to the
> clk2 domain before applying it to the mux chain using 2 regs as per Mikes
> suggestion. 

You're right. If only I had enough ressources in the FPGA... But the question
for timing constraints would be the same. The problem is just shifted in front
of the synchronizing FFs.

Best regards,
Leo

Article: 35724
Subject: Re: JTAG-Programmer Linux
From: Stefano Ho <chho2@cse.cuhk.edu.hk>
Date: 15 Oct 2001 16:06:57 GMT
Links: << >>  << T >>  << A >>
Marc Reinert <reinert@tu-harburg.de> wrote:
> Is there any good JTAG-Programmer that I can use under Linux to program
> Xilinx FPGAs and PROMs over the Parallel III Cable?

> I thought the Xilinx JTAG-Programmer is free, but I didn't find a place
> to download it in a linux version.

> Any good ideas?

> Regards

> Marc

try this:
http://www.cse.cuhk.edu.hk/~khtsoi/project/Xilinux/


regards,
stefano



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search