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 39400

Article: 39400
Subject: Re: Xilinx ISE 3.3 upgrade to 4.1
From: hamish@cloud.net.au
Date: 08 Feb 2002 13:56:44 GMT
Links: << >>  << T >>  << A >>
Jui Tan <juitongtanSPAM@yahoo.com> wrote:
> 2 weeks ago, I decided to upgrade my tools to version 4.1.  After the
> upgrade, I ran the same design through version 4.1 and got a whole list of
> timing violations (some constraints are violated due to gate delays alone).
> I called the Xilinx tech hotline, and they said that the timing library for
> version 4.1 reflects the characteristics of the latest silicon.  He told me

Yep. The newer software has newer (hopefully more accurate) timing
data. The speed files change quite regularly, even between service packs.

> I am sure I am not the only person with this problem.  If you have a virtexE
> design in production PAR with ISE 3.3, what have/would you do?

The Virtex-E speed files are still changing. The 4.1i service pack 3
release has v1.65 of the Virtex-E speed files, and there's some more
slow downs in those (CLB RAM setup time, from memory). A previous
version slowed down some block RAM control inputs. The 3.3 service
pack 8 speed files doubled the block RAM clock-to-out delay.

So you have a Virtex-E design which meets timing in 3.3 and works
in all of your testing with the devices you have. So do you
make the effort to get it to meeting timing with the newer speed data?
Good question. I think of it this way -- the speed files reflect what
the silicon could be, at worst.

That your design works on the silicon you have unfortunately isn't
proof that it will work on every part that you ever ship. Theoretically
Xilinx could actually change the silicon to match pessimistic speed
files if that would improve yield, product cost etc.

So, I've spent the last week updating some old designs and I'll
be spending most of next week on it too. Not much fun but necessary.
(Actually, there is some real design work to be done so we're
upgrading to the last speed files at the same time -- we don't
generally re-route designs just for new timing data.)


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 39401
Subject: Re: Xilinx ISE 3.3 upgrade to 4.1
From: hamish@cloud.net.au
Date: 08 Feb 2002 13:58:15 GMT
Links: << >>  << T >>  << A >>
"Mike Johnson" <mikej <NOSPAM>freeuk.com> wrote:
> In the past I've generally found that the speed files have become less
> pessimistic as Xilinx have refined them, so the chips 'get faster'. No
> excuse for this though as I thought 3.3 sp8 virtexE speedfiles were final ?

No, there are updates for Virtex-E as recently as 4.1 SP3 (v1.65 speed
files). I would say that in almost every release of the Virtex-E speed
files in the past year, some part of the device has gotten slower.
I haven't seen any speed ups. Routes that were easy 18 months ago
are killers these days.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 39402
Subject: Re: Xilinx DCM question anyone? (or Peter if he is there?)
From: "Tim Ottley" <tim.ottley@elixent.com>
Date: Fri, 8 Feb 2002 14:02:50 -0000
Links: << >>  << T >>  << A >>
Hi Philip,

I had a feeling that it was going to be bitstream-only configurable
but you have confirmed it for me.  Shame really, but we will have to
go with an external single-chip programmable clockgen then, as we
do need the ability to sweep through a range of frequencies from
under the Vertex's control.

Thanks very much for your help.

Best regards,
                       Tim Ottley

"Philip Freidin" <philip@fliptronics.com> wrote in message
news:1ni76ugsrmn4i936l9r7vm64rfl2pf89l8@4ax.com...
> On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com>
wrote:
> >Hi Peter et al,
> >
> >I wish to use a DCM as a programmable and sweepable clock source
> >within a Vertex2 device.  It will only be supplying its output to an
> >external pin,
> >but the output will need to be gatable.
> >
> >I want to use it in the Digital Frequency Synthesis mode, with registers
to
> >hold
> >the Multiplier & Divider values so that the output frequency can be
changed
> >at
> >any time.  The only problem I have is that I cannot find the M & D
control
> >signals
> >on the instance of the DCM block.  I  believe that I will need to use the
> >CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it
> >is instanced, but I am not clear how I can use these in a dynamically
> >adjustable way.
> >
> >Can anyone tell me if this is possible, and if so, a little snippet of
> >Verilog to illustrate?
> >(pretty please)
> >
> >Thanks,
> >              Tim Ottley.
> >
>
> This is do-able, but FAR from easy. The M and D values are parameters
> that end up being encoded in the bit stream. There is no direct runtime
> access to them.
>
> The Virtex-II devices do support run-time partial configuration.
>
> You would need to find the location of these bits in the bitstream,
> and create a partial reconfig to modify them on the fly. Given the
> issues with DCM reset, I would suspect that to be succesful, you would
> need to assert the DCM reset, then do the reconfig, then release DCM
> reset. Since configuration is by frames, you would also have to build
> reconfiguration frames that did not damage other parts of your design.
>
> So I dont think that sweeping is going to be possible.
>
> To see what you are up against, create a design with a DCM in it.
> and create an RBT file from it. Using the XDL interface to the
> NCD file, edit the M and D, convert back to NCD and create a new
> RBT. Compare to see how it changed.
>
> In the XDL, look for something like this:
>
> inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 ,
>  cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW
>       STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE
>       FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2
>       FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF
>       STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF
>       PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC
>       RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF
>       CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF
>       CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF
>       CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE
>       CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF
>       DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4
>       PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS::
>       LL_HEX_COM:: LL_HEX_MISC::"
>
>
> M and D are on the third last line. BUT ... there seems to be
> quite a few other attributes that are being automatically set
> by the sw, that are not documented for user control.
>
> The command I used to create the above was:
>
>    xdl -ncd2xdl app_1.ncd
>
> I am using M4.1i sp3
>
> Good luck,
>
> Philip Freidin
>
>
> Philip Freidin
> Fliptronics



Article: 39403
Subject: Re: Design with Triscend E5
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Fri, 08 Feb 2002 14:25:28 GMT
Links: << >>  << T >>  << A >>

"Josan Moreno" <joseanmo@unex.es> wrote in message
news:a3uh7l$qjh$1@emilio.unex.es...
> Hi,
> I'm looking for an RTL description or PLI module of the 8051 included in
> Triscend for simulation purposes.
> Thanks.

Josan,
    What's wrong with contacting Triscend for this product?
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA



Article: 39404
Subject: the problem of post simulation
From: shengyu_shen@hotmail.com (ssy)
Date: 8 Feb 2002 07:00:05 -0800
Links: << >>  << T >>  << A >>
Hi everyone

I am using synplify pro 6.2.4 to synthesis, after synthesis, I use the
.vm file and the quartus II 1.1 library file to perform post syn
simulation,

but it seems that all register do not change even the simulation time
progress forward for a long time.

it seems that the external clock can not enter the design

why?

BTW : I uncheck the "disable io insertion" option in synplify,I think
this may be the cause.

Article: 39405
Subject: Re: the cause of the simulation/synthesis mismatch
From: shengyu_shen@hotmail.com (ssy)
Date: 8 Feb 2002 07:07:32 -0800
Links: << >>  << T >>  << A >>
Hi
I am using synplify pro 6.2.4 to synthesis, after synthesis, I use the
.vm file and the quartus II 1.1 library file to perform post syn
simulation in modelsim,

but it seems that all register do not change even the simulation time
progress forward for a long time.

it seems that the external clock can not enter the design

why?

BTW : I uncheck the "disable io insertion" option in synplify,I think
this may be the cause.

and about the warning, there are following warning

1 some output pin have undriven bit
2 many many many register have been removed or stuck at a fix value

amd about the replace, in the synthesis , the syntheser have optimize
across the border of module,how to deal with this

kayrock66@yahoo.com (Jay) wrote in message news:<d049f91b.0202061722.56bb6195@posting.google.com>...
> If you are new at using HDL's to design ciruits, it is very possible
> you have coded something that will not behave the same in gates (post
> synthesis) as it does in RTL form.  Often time the sythesizer will
> warn you of these coding style issues, but not always.  You should run
> a post syth, pre P&R simulation against you existing test-bench and
> see if it flys.  If it doesn't you, among other techniques, you can
> replace on by one, each module with its RTL version until you make it
> work.
> 
> Good luck to you!
> 
> shengyu_shen@hotmail.com (ssy) wrote in message news:<f4a5f64f.0201310054.234aa10f@posting.google.com>...
> > Hi every one
> > 
> > I am using sopc board from altera, it hold an APEX20k400E, I am using
> > synplicity 6.2.4 to synthesis and then use quartus II 1.1 to P&R,
> > 
> > my design is an cpu, the cpu hold one cpu core(design by me), an
> > interconnect network(design by other), and some slave device(design by
> > my team member)
> > 
> > the cpu core have two master port to fetch instruction and data
> > 
> > the interconnect network have 8 master and 16 slave, any unuse port's
> > output pin will not connect and input pin will assign 0,
> > 
> > I run pre syn rtl simulation, all ok,but after burn on the board, it
> > is error,
> > 
> > I want to know possible cause of synthesis/simulation mismatch.

Article: 39406
Subject: Re: Xilinx ISE 3.3 upgrade to 4.1
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 08 Feb 2002 15:53:45 +0000
Links: << >>  << T >>  << A >>


hamish@cloud.net.au wrote:

> "Mike Johnson" <mikej <NOSPAM>freeuk.com> wrote:
> > In the past I've generally found that the speed files have become less
> > pessimistic as Xilinx have refined them, so the chips 'get faster'. No
> > excuse for this though as I thought 3.3 sp8 virtexE speedfiles were final ?
>
> No, there are updates for Virtex-E as recently as 4.1 SP3 (v1.65 speed
> files). I would say that in almost every release of the Virtex-E speed
> files in the past year, some part of the device has gotten slower.
> I haven't seen any speed ups. Routes that were easy 18 months ago
> are killers these days.
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Hamish.

Thanks for this message - I was just about to download SP3!



Article: 39407
Subject: Re: Pseudorandom Bitstream
From: Stromeko@nexgo.de (Achim Gratz)
Date: 8 Feb 2002 08:04:40 -0800
Links: << >>  << T >>  << A >>
[...]

OK, let me summarize to see if I got everything correct:

1. From a uniformly distributed sequence of n-bit numbers one can
generate a non-uniformly distributed single-bitstream by squashing the
n-bit by a comparator, allowing for densities to be chosen from 0 to 1
in 1/2^n increments. Interestingly (and in relation to my original
question) this seems to mean that I can partition the n-bit into
(j+k)-bit and obtain 2^j completely uncorrelated sequences in 1/2^k
increments and densities ranging from 0 to 1/2^j by using 2^j
two-sided comparators with non-overlapping ranges. Using the binary
partition scheme from above that simplifies to just a one-sided
comparator in k bits and a decoder that enables/disables the output
based on j bits.

2. Pseudorandom n-bitstreams may be produced in various ways, which
relate to polynomials in GF2 (esp. CRC polynomials). A parallel output
can be implemented by unrolling and pipelining an LFSR for instance or
you may just go for the polynomial directly.

(I seem to remember that some/most of these polynomials are
cryptographically weak, but that isn't an issue for the application I
have in mind. I just need a white spectrum.)


Achim.

Article: 39408
Subject: NT parallel port driver
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 08 Feb 2002 16:12:56 +0000
Links: << >>  << T >>  << A >>
I'm after an WinNT/2K Parallel port driver so I can realise a Flash
based FPGA config data store.

I'd prefer free or share ware but a modest cost wouldn't be out of the
question. Could someone point me in the right direction ?


Article: 39409
Subject: Help on bus interface needed.
From: Richard Meester <rme@quest-innovations.com>
Date: Fri, 08 Feb 2002 17:16:03 +0100
Links: << >>  << T >>  << A >>
Hi All,

I have some problems finding a good design practice for a bus-interface.

We have a processor running internally at 100Mhz, and externally at
50Mhz (2 internal bus cycles used for 1 complete external bus cycle).
Now the addresses are set, the cs lines are set, the re_n and we_n
signals are set and the data is set or read. I know all the timing
variables on these lines.

Now i need to design a bus interface, but i want the internal clock to
run at least at 66 Mhz because i need to access ram at this speed and
want to keep the internal clock speeds at the same speed.

Now how can i best trigger my internal signals, the we_n line goes
active low after 8 nsecs of valid data, should i use this signal and
feed it into a fflop to trigger on, or should i let the flop trigger at
the internal clock speed and detect that the line has changed state and
take action from there, or should i make the desing completely
combinatorial?

Thanks in advance,

Richard

--


Quest Innovations
tel: +31 (0) 227 604046
fax: +31 (0) 227 604053
http://www.quest-innovations.com



Article: 39410
Subject: Re: NT parallel port driver
From: Dave Vanden Bout <devb@xess.com>
Date: Fri, 08 Feb 2002 11:28:19 -0500
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:

> I'm after an WinNT/2K Parallel port driver so I can realise a Flash
> based FPGA config data store.
>
> I'd prefer free or share ware but a modest cost wouldn't be out of the
> question. Could someone point me in the right direction ?

One package is the DriverLINX software and driver.  Check for it at
www.sstnet.com.  We also have an installation file for it (port95nt.exe)
at
http://www.xess.com/ho07000.html.

Another option is UNIIO.  The source for this is completely available so
you
can compile the parts you need.  Look for it at www.bbdsoft.com.


--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||



Article: 39411
Subject: Re: Xilinx DCM question anyone? (or Peter if he is there?)
From: John_H <johnhandwork@mail.com>
Date: Fri, 08 Feb 2002 16:44:10 GMT
Links: << >>  << T >>  << A >>
But do you really need the DCM to do all the work?

If you can tolerate jitter - if - then there may be a way to get your clock
generation capability without using an external solution.  The global clock mux
is a wonderful little primitive in the Virtex-II which can give glitchless
transitions from one clock to another.  Consider 1) producing a high frequency
clock with the DCM(s), 2) using several phase-shifted versions of the same clock
(1/4 cycle intervals, perhaps), 3) using the DDR interface to give you beautiful
edges, 4) using an accumulator based scheme to transition between phase offsets.

If you need a wide range of frequencies (>12% ?) this approach probably won't do
you much good but if your frequency range is tight, adding a phase offset of 1/8
cycle of the DCM frequency can produce some beautiful time-domain results.
Frequency domain results would be a bit choppy since you're applying a quantized
phase-modulation technique to get your output.

It's a bit of work compared to wiring up a PLL chip but if you need the most
compact implementation this technique can be your friend.

- John_H


Tim Ottley wrote:

> Hi Philip,
>
> I had a feeling that it was going to be bitstream-only configurable
> but you have confirmed it for me.  Shame really, but we will have to
> go with an external single-chip programmable clockgen then, as we
> do need the ability to sweep through a range of frequencies from
> under the Vertex's control.
>
> Thanks very much for your help.
>
> Best regards,
>                        Tim Ottley
>
> "Philip Freidin" <philip@fliptronics.com> wrote in message
> news:1ni76ugsrmn4i936l9r7vm64rfl2pf89l8@4ax.com...
> > On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com>
> wrote:
> > >Hi Peter et al,
> > >
> > >I wish to use a DCM as a programmable and sweepable clock source
> > >within a Vertex2 device.  It will only be supplying its output to an
> > >external pin,
> > >but the output will need to be gatable.
> > >
> > >I want to use it in the Digital Frequency Synthesis mode, with registers
> to
> > >hold
> > >the Multiplier & Divider values so that the output frequency can be
> changed
> > >at
> > >any time.  The only problem I have is that I cannot find the M & D
> control
> > >signals
> > >on the instance of the DCM block.  I  believe that I will need to use the
> > >CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it
> > >is instanced, but I am not clear how I can use these in a dynamically
> > >adjustable way.
> > >
> > >Can anyone tell me if this is possible, and if so, a little snippet of
> > >Verilog to illustrate?
> > >(pretty please)
> > >
> > >Thanks,
> > >              Tim Ottley.
> > >
> >
> > This is do-able, but FAR from easy. The M and D values are parameters
> > that end up being encoded in the bit stream. There is no direct runtime
> > access to them.
> >
> > The Virtex-II devices do support run-time partial configuration.
> >
> > You would need to find the location of these bits in the bitstream,
> > and create a partial reconfig to modify them on the fly. Given the
> > issues with DCM reset, I would suspect that to be succesful, you would
> > need to assert the DCM reset, then do the reconfig, then release DCM
> > reset. Since configuration is by frames, you would also have to build
> > reconfiguration frames that did not damage other parts of your design.
> >
> > So I dont think that sweeping is going to be possible.
> >
> > To see what you are up against, create a design with a DCM in it.
> > and create an RBT file from it. Using the XDL interface to the
> > NCD file, edit the M and D, convert back to NCD and create a new
> > RBT. Compare to see how it changed.
> >
> > In the XDL, look for something like this:
> >
> > inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 ,
> >  cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW
> >       STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE
> >       FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2
> >       FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF
> >       STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF
> >       PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC
> >       RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF
> >       CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF
> >       CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF
> >       CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE
> >       CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF
> >       DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4
> >       PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS::
> >       LL_HEX_COM:: LL_HEX_MISC::"
> >
> >
> > M and D are on the third last line. BUT ... there seems to be
> > quite a few other attributes that are being automatically set
> > by the sw, that are not documented for user control.
> >
> > The command I used to create the above was:
> >
> >    xdl -ncd2xdl app_1.ncd
> >
> > I am using M4.1i sp3
> >
> > Good luck,
> >
> > Philip Freidin
> >
> >
> > Philip Freidin
> > Fliptronics


Article: 39412
Subject: Re: Xilinx ISE 3.3 upgrade to 4.1
From: John_H <johnhandwork@mail.com>
Date: Fri, 08 Feb 2002 16:46:08 GMT
Links: << >>  << T >>  << A >>
Now that you know some of the timing numbers are worse you can skip downloading the
update and your parts won't run slower!

  ( ? )


Rick Filipkiewicz wrote:

> hamish@cloud.net.au wrote:
>
> > "Mike Johnson" <mikej <NOSPAM>freeuk.com> wrote:
> > > In the past I've generally found that the speed files have become less
> > > pessimistic as Xilinx have refined them, so the chips 'get faster'. No
> > > excuse for this though as I thought 3.3 sp8 virtexE speedfiles were final ?
> >
> > No, there are updates for Virtex-E as recently as 4.1 SP3 (v1.65 speed
> > files). I would say that in almost every release of the Virtex-E speed
> > files in the past year, some part of the device has gotten slower.
> > I haven't seen any speed ups. Routes that were easy 18 months ago
> > are killers these days.
> >
> > Hamish
> > --
> > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
>
> Hamish.
>
> Thanks for this message - I was just about to download SP3!


Article: 39413
Subject: Re: Xilinx DCM question anyone? (or Peter if he is there?)
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 08 Feb 2002 08:51:25 -0800
Links: << >>  << T >>  << A >>
Tim,

There is someone out here (I can't remember who) who is going to use the ICAP
feature, and reconfigure the bits he needs for different M and D values.

The ICAP is a two for one mux that switches all of the config pins outside the
part, to inside the part, for use internally.

Use bitgen -r name1 name2 to get a diff stream that is just the differences
between the two streams to reconfigure what you want.

Put the diff streams in a BRAM, or external part, and either use ICAP, or
external reconfig to change M and D.

You MUST reset the DCM after reconfig.

Austin

Tim Ottley wrote:

> Hi Philip,
>
> I had a feeling that it was going to be bitstream-only configurable
> but you have confirmed it for me.  Shame really, but we will have to
> go with an external single-chip programmable clockgen then, as we
> do need the ability to sweep through a range of frequencies from
> under the Vertex's control.
>
> Thanks very much for your help.
>
> Best regards,
>                        Tim Ottley
>
> "Philip Freidin" <philip@fliptronics.com> wrote in message
> news:1ni76ugsrmn4i936l9r7vm64rfl2pf89l8@4ax.com...
> > On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com>
> wrote:
> > >Hi Peter et al,
> > >
> > >I wish to use a DCM as a programmable and sweepable clock source
> > >within a Vertex2 device.  It will only be supplying its output to an
> > >external pin,
> > >but the output will need to be gatable.
> > >
> > >I want to use it in the Digital Frequency Synthesis mode, with registers
> to
> > >hold
> > >the Multiplier & Divider values so that the output frequency can be
> changed
> > >at
> > >any time.  The only problem I have is that I cannot find the M & D
> control
> > >signals
> > >on the instance of the DCM block.  I  believe that I will need to use the
> > >CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it
> > >is instanced, but I am not clear how I can use these in a dynamically
> > >adjustable way.
> > >
> > >Can anyone tell me if this is possible, and if so, a little snippet of
> > >Verilog to illustrate?
> > >(pretty please)
> > >
> > >Thanks,
> > >              Tim Ottley.
> > >
> >
> > This is do-able, but FAR from easy. The M and D values are parameters
> > that end up being encoded in the bit stream. There is no direct runtime
> > access to them.
> >
> > The Virtex-II devices do support run-time partial configuration.
> >
> > You would need to find the location of these bits in the bitstream,
> > and create a partial reconfig to modify them on the fly. Given the
> > issues with DCM reset, I would suspect that to be succesful, you would
> > need to assert the DCM reset, then do the reconfig, then release DCM
> > reset. Since configuration is by frames, you would also have to build
> > reconfiguration frames that did not damage other parts of your design.
> >
> > So I dont think that sweeping is going to be possible.
> >
> > To see what you are up against, create a design with a DCM in it.
> > and create an RBT file from it. Using the XDL interface to the
> > NCD file, edit the M and D, convert back to NCD and create a new
> > RBT. Compare to see how it changed.
> >
> > In the XDL, look for something like this:
> >
> > inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 ,
> >  cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW
> >       STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE
> >       FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2
> >       FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF
> >       STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF
> >       PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC
> >       RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF
> >       CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF
> >       CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF
> >       CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE
> >       CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF
> >       DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4
> >       PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS::
> >       LL_HEX_COM:: LL_HEX_MISC::"
> >
> >
> > M and D are on the third last line. BUT ... there seems to be
> > quite a few other attributes that are being automatically set
> > by the sw, that are not documented for user control.
> >
> > The command I used to create the above was:
> >
> >    xdl -ncd2xdl app_1.ncd
> >
> > I am using M4.1i sp3
> >
> > Good luck,
> >
> > Philip Freidin
> >
> >
> > Philip Freidin
> > Fliptronics


Article: 39414
Subject: Re: Xilinx DCM question anyone? (or Peter if he is there?)
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 08 Feb 2002 08:52:33 -0800
Links: << >>  << T >>  << A >>
PS:

Peter is out on a secret mission, so he may or may not answer as he reaches
civilized locations.

Expect him to travel electronically under an alias.

Austin

Austin Lesea wrote:

> Tim,
>
> There is someone out here (I can't remember who) who is going to use the ICAP
> feature, and reconfigure the bits he needs for different M and D values.
>
> The ICAP is a two for one mux that switches all of the config pins outside the
> part, to inside the part, for use internally.
>
> Use bitgen -r name1 name2 to get a diff stream that is just the differences
> between the two streams to reconfigure what you want.
>
> Put the diff streams in a BRAM, or external part, and either use ICAP, or
> external reconfig to change M and D.
>
> You MUST reset the DCM after reconfig.
>
> Austin
>
> Tim Ottley wrote:
>
> > Hi Philip,
> >
> > I had a feeling that it was going to be bitstream-only configurable
> > but you have confirmed it for me.  Shame really, but we will have to
> > go with an external single-chip programmable clockgen then, as we
> > do need the ability to sweep through a range of frequencies from
> > under the Vertex's control.
> >
> > Thanks very much for your help.
> >
> > Best regards,
> >                        Tim Ottley
> >
> > "Philip Freidin" <philip@fliptronics.com> wrote in message
> > news:1ni76ugsrmn4i936l9r7vm64rfl2pf89l8@4ax.com...
> > > On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com>
> > wrote:
> > > >Hi Peter et al,
> > > >
> > > >I wish to use a DCM as a programmable and sweepable clock source
> > > >within a Vertex2 device.  It will only be supplying its output to an
> > > >external pin,
> > > >but the output will need to be gatable.
> > > >
> > > >I want to use it in the Digital Frequency Synthesis mode, with registers
> > to
> > > >hold
> > > >the Multiplier & Divider values so that the output frequency can be
> > changed
> > > >at
> > > >any time.  The only problem I have is that I cannot find the M & D
> > control
> > > >signals
> > > >on the instance of the DCM block.  I  believe that I will need to use the
> > > >CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it
> > > >is instanced, but I am not clear how I can use these in a dynamically
> > > >adjustable way.
> > > >
> > > >Can anyone tell me if this is possible, and if so, a little snippet of
> > > >Verilog to illustrate?
> > > >(pretty please)
> > > >
> > > >Thanks,
> > > >              Tim Ottley.
> > > >
> > >
> > > This is do-able, but FAR from easy. The M and D values are parameters
> > > that end up being encoded in the bit stream. There is no direct runtime
> > > access to them.
> > >
> > > The Virtex-II devices do support run-time partial configuration.
> > >
> > > You would need to find the location of these bits in the bitstream,
> > > and create a partial reconfig to modify them on the fly. Given the
> > > issues with DCM reset, I would suspect that to be succesful, you would
> > > need to assert the DCM reset, then do the reconfig, then release DCM
> > > reset. Since configuration is by frames, you would also have to build
> > > reconfiguration frames that did not damage other parts of your design.
> > >
> > > So I dont think that sweeping is going to be possible.
> > >
> > > To see what you are up against, create a design with a DCM in it.
> > > and create an RBT file from it. Using the XDL interface to the
> > > NCD file, edit the M and D, convert back to NCD and create a new
> > > RBT. Compare to see how it changed.
> > >
> > > In the XDL, look for something like this:
> > >
> > > inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 ,
> > >  cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW
> > >       STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE
> > >       FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2
> > >       FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF
> > >       STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF
> > >       PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC
> > >       RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF
> > >       CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF
> > >       CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF
> > >       CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE
> > >       CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF
> > >       DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4
> > >       PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS::
> > >       LL_HEX_COM:: LL_HEX_MISC::"
> > >
> > >
> > > M and D are on the third last line. BUT ... there seems to be
> > > quite a few other attributes that are being automatically set
> > > by the sw, that are not documented for user control.
> > >
> > > The command I used to create the above was:
> > >
> > >    xdl -ncd2xdl app_1.ncd
> > >
> > > I am using M4.1i sp3
> > >
> > > Good luck,
> > >
> > > Philip Freidin
> > >
> > >
> > > Philip Freidin
> > > Fliptronics


Article: 39415
Subject: Re: NT parallel port driver ...Any serial NT drivers?
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Fri, 08 Feb 2002 13:11:42 -0500
Links: << >>  << T >>  << A >>
Does any one have serial drivers for WinNT/2K?  I need to get a driver, etc.
to allow me to talk to an FPGA based device via the com ports in an NT
machine.

Dave Vanden Bout wrote:

> Rick Filipkiewicz wrote:
>
> > I'm after an WinNT/2K Parallel port driver so I can realise a Flash
> > based FPGA config data store.
> >
> > I'd prefer free or share ware but a modest cost wouldn't be out of the
> > question. Could someone point me in the right direction ?
>
> One package is the DriverLINX software and driver.  Check for it at
> www.sstnet.com.  We also have an installation file for it (port95nt.exe)
> at
> http://www.xess.com/ho07000.html.
>
> Another option is UNIIO.  The source for this is completely available so
> you
> can compile the parts you need.  Look for it at www.bbdsoft.com.
>
> --
> || Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
> || devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
> || http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||


Article: 39416
Subject: Modelsim questions
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Fri, 08 Feb 2002 13:57:20 -0500
Links: << >>  << T >>  << A >>
I am designing a system with multiple FPGA's. The reason I am using
multiple FPGA's is that one of the boards is in a separate location and
the third board is duplicated several times in the system.  I would like
to use modelsim to simulate it with separate FPGA's.  My ultimate goal
is to use post place and route timings for all devices in one
simulation.  Is this do-able with modelsim XE/ starter 5.5b? I know that
it will be slow but that is not a problem for me. I can allow it to run
overnight or over the weekend if need be.

Also, I cannot get modelsim to recognize my coregen parts at the
behavioral level.  How do I get that to work?


Article: 39417
Subject: Re: solutions manuals, and no they are not for school
From: Jerry Avins <jya@ieee.org>
Date: Fri, 08 Feb 2002 14:09:49 -0500
Links: << >>  << T >>  << A >>
Rick Lyons wrote:
> 
> On Thu, 07 Feb 2002 14:14:00 -0500, Jerry Avins <jya@ieee.org> wrote:
> 
>   (snipped)
> 
> >I learned about DC attenuation in order to design telegraph lines - aren't
> >all curricula outdated? - but nothing goes to waste: DC power
> >transmission is big these days, and the math hasn't changed.)
> >
> >Jerry
> 
> Telegraph lines!!  Maybe I was right when I
> once posted that you knew Abraham Lincoln personally.
> 
> [-Rick-]

Not true! But had he he studied engineering instead of law, I might have
used some of his cast-off texts. I know how to build an Alexanderson
alternator to generate RF directly with a rotating machine (and I live
near the first major installation.) I used to be a whiz at tube design,
and there were no courses in logic design, let alone computers when I
graduated in 1962 (at age 30). I can design (or at least evaluate a
design well enough to avoid being sold garbage) power-station steam
turbines -- Keenen and Keyes' "Thermodynamic Properties of Steam" is on
my book shelf. I know a Worthington steam-operated boiler-return pump on
sight, and I can compound a DC generator any way that's called for. So
why not telegraph? At least I got as far as simplex connection to ride a
free telegraph line on top of a telephone pair, and simultaneous
east-west signaling on a single telegraph wire with a new-fangled
"duplex" connection. There's a lot of stuff in there that only seems
useless: it gives me shortcuts when thinking about new stuff. It's nice
to have learned to design commercial antenna towers, too (down to
figuring the rivet patterns), but that has been useful only privately.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------

Article: 39418
Subject: Re: Xilinx DCM question anyone? (or Peter if he is there?)
From: Ray Andraka <ray@andraka.com>
Date: Fri, 08 Feb 2002 19:13:51 GMT
Links: << >>  << T >>  << A >>
What is the frequency range, step resolution, and jitter requirements for your
swept frequency?  If they are not too high, you could  use a Direct digital
synthesizer with a high rate clock.  Carefully designed you could get the
effective master clock in the high hundreds of MHz in VirtexII.

Tim Ottley wrote:

> Hi Philip,
>
> I had a feeling that it was going to be bitstream-only configurable
> but you have confirmed it for me.  Shame really, but we will have to
> go with an external single-chip programmable clockgen then, as we
> do need the ability to sweep through a range of frequencies from
> under the Vertex's control.
>
> Thanks very much for your help.
>
> Best regards,
>                        Tim Ottley
>
> "Philip Freidin" <philip@fliptronics.com> wrote in message
> news:1ni76ugsrmn4i936l9r7vm64rfl2pf89l8@4ax.com...
> > On Fri, 8 Feb 2002 09:34:38 -0000, "Tim Ottley" <tim.ottley@elixent.com>
> wrote:
> > >Hi Peter et al,
> > >
> > >I wish to use a DCM as a programmable and sweepable clock source
> > >within a Vertex2 device.  It will only be supplying its output to an
> > >external pin,
> > >but the output will need to be gatable.
> > >
> > >I want to use it in the Digital Frequency Synthesis mode, with registers
> to
> > >hold
> > >the Multiplier & Divider values so that the output frequency can be
> changed
> > >at
> > >any time.  The only problem I have is that I cannot find the M & D
> control
> > >signals
> > >on the instance of the DCM block.  I  believe that I will need to use the
> > >CLKFX_MULTIPLY and CLKFX_DIVIDE parameters for the DCM when it
> > >is instanced, but I am not clear how I can use these in a dynamically
> > >adjustable way.
> > >
> > >Can anyone tell me if this is possible, and if so, a little snippet of
> > >Verilog to illustrate?
> > >(pretty please)
> > >
> > >Thanks,
> > >              Tim Ottley.
> > >
> >
> > This is do-able, but FAR from easy. The M and D values are parameters
> > that end up being encoded in the bit stream. There is no direct runtime
> > access to them.
> >
> > The Virtex-II devices do support run-time partial configuration.
> >
> > You would need to find the location of these bits in the bitstream,
> > and create a partial reconfig to modify them on the fly. Given the
> > issues with DCM reset, I would suspect that to be succesful, you would
> > need to assert the DCM reset, then do the reconfig, then release DCM
> > reset. Since configuration is by frames, you would also have to build
> > reconfiguration frames that did not damage other parts of your design.
> >
> > So I dont think that sweeping is going to be possible.
> >
> > To see what you are up against, create a design with a DCM in it.
> > and create an RBT file from it. Using the XDL interface to the
> > NCD file, edit the M and D, convert back to NCD and create a new
> > RBT. Compare to see how it changed.
> >
> > In the XDL, look for something like this:
> >
> > inst "dcm_0" "DCM" , placed TIOIBRAMC1 DCM_X0Y1 ,
> >  cfg "DLL_FREQUENCY_MODE::LOW DFS_FREQUENCY_MODE::LOW
> >       STARTUP_WAIT::#OFF DUTY_CYCLE_CORRECTION::TRUE
> >       FACTORY_JF2::0X80 FACTORY_JF1::0XC0 CLKDV_DIVIDE::2
> >       FREEZEDLLINV::#OFF FREEZEDFSINV::#OFF STSADRS0INV::#OFF
> >       STSADRS1INV::#OFF STSADRS2INV::#OFF STSADRS3INV::#OFF
> >       PSCLKINV::PSCLK PSENINV::PSEN PSINCDECINV::PSINCDEC
> >       RSTINV::RST DSSENINV::DSSEN_B CTLOSC2INV::#OFF
> >       CTLOSC1INV::#OFF CTLGOINV::#OFF CTLSEL0INV::#OFF
> >       CTLSEL1INV::#OFF CTLSEL2INV::#OFF CTLMODEINV::#OFF
> >       CLK_FEEDBACK::1X CLKOUT_PHASE_SHIFT::VARIABLE
> >       CLKIN_DIVIDE_BY_2::#OFF VERY_HIGH_FREQUENCY::#OFF
> >       DSS_MODE::NONE DCM:dcm_0: CLKFX_DIVIDE::1 CLKFX_MULTIPLY::4
> >       PHASE_SHIFT::0 LL_HEX_DLLS:: LL_HEX_DLLC:: LL_HEX_DFS::
> >       LL_HEX_COM:: LL_HEX_MISC::"
> >
> >
> > M and D are on the third last line. BUT ... there seems to be
> > quite a few other attributes that are being automatically set
> > by the sw, that are not documented for user control.
> >
> > The command I used to create the above was:
> >
> >    xdl -ncd2xdl app_1.ncd
> >
> > I am using M4.1i sp3
> >
> > Good luck,
> >
> > Philip Freidin
> >
> >
> > Philip Freidin
> > Fliptronics

--
--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: 39419
Subject: Re: Modelsim questions
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 08 Feb 2002 11:23:15 -0800
Links: << >>  << T >>  << A >>
Theron Hicks wrote:
> 
> I am designing a system with multiple FPGA's.  My ultimate goal
> is to use post place and route timings for all devices in one
> simulation.  Is this do-able with modelsim XE/ starter 5.5b? 

Modelsim knows nothing about devices other than
what you include in the technology library, so
I see no reason why that would be a problem.

> Also, I cannot get modelsim to recognize my coregen parts at the
> behavioral level.  How do I get that to work?

Coregen parts are not behavioral. 
They are device specific netlists.

The alternative is to write and
synthesizer your own core functions.

  -- Mike Treseler

Article: 39420
Subject: Re: CLKDLL x4 problem
From: Ray Andraka <ray@andraka.com>
Date: Fri, 08 Feb 2002 19:35:27 GMT
Links: << >>  << T >>  << A >>
The 100MHz out of the Dini board might be tough to do.  You could go to a
DDR output where each edge of the output clock is active.  Is your input
fixed at 10 MHz, or is 10 MHz just a convenience?  Can you source the
pattern generator clock out of the FPGA perhaps, or use a multiplied clock
coming int at say 40 MHz?  Without the big picture it is awful hard to
offer solutions that meet the needs of your system.  As Jerry Avins' tag
line sometimes says: Engineering is the art of making something you want
out of the things that you have.  Perhaps you should take stock of what is
available to you and tailor a solution to fit within your means?

Antonio wrote:

> Hi Ray,
> the problem is synchronization between the data arriving from the
> pattern generator and the clocks that are inside FPGA, my idea to use
> clkdll was to enter inside the FPGA with the clock (25MHz for example)
> associated to the data and coming from the pattern generator, from
> that clock to obtain a 100MHz master clock via the CLKDLL and in this
> way is all synchronized, but 100MHz out of the DINI board seems to be
> not achieved.
> If I choose your schema 40MHz quartz plus clkdll divider, I've the
> problem that this divided frequency, maybe 10MHz is not synchronized
> to the 10 MHz coming from the pattern generator, about this I'm
> studing the opportunity to insert a FIFO which write is driven from
> the pattern generator clock and read is driven from the board reduced
> clock.
> What do you think about this, there's a simple way to obtain the same
> results ??
>
>                                 Antonio

--
--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: 39421
Subject: Re: Pseudorandom Bitstream
From: Ray Andraka <ray@andraka.com>
Date: Fri, 08 Feb 2002 19:53:32 GMT
Links: << >>  << T >>  << A >>


Achim Gratz wrote:

> [...]
>
> OK, let me summarize to see if I got everything correct:
>
> 1. From a uniformly distributed sequence of n-bit numbers one can
> generate a non-uniformly distributed single-bitstream by squashing the
> n-bit by a comparator, allowing for densities to be chosen from 0 to 1
> in 1/2^n increments. Interestingly (and in relation to my original
> question) this seems to mean that I can partition the n-bit into
> (j+k)-bit and obtain 2^j completely uncorrelated sequences in 1/2^k
> increments and densities ranging from 0 to 1/2^j by using 2^j
> two-sided comparators with non-overlapping ranges. Using the binary
> partition scheme from above that simplifies to just a one-sided
> comparator in k bits and a decoder that enables/disables the output
> based on j bits.

Hadn't looked at it that way, but yeah, that sounds about right.

>
>
> 2. Pseudorandom n-bitstreams may be produced in various ways, which
> relate to polynomials in GF2 (esp. CRC polynomials). A parallel output
> can be implemented by unrolling and pipelining an LFSR for instance or
> you may just go for the polynomial directly.

Yep.

>
>
> (I seem to remember that some/most of these polynomials are
> cryptographically weak, but that isn't an issue for the application I
> have in mind. I just need a white spectrum.)

An LFSR by itself is cryptographically weak regardless of the polynomial
because you only need N+1 bits to recover the key and initial state, and
therefore the plain text stream.  Nevertheless, LFSRs do fall into the
class of GF2 algorithms.

>
>
> Achim.

--
--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: 39422
Subject: Schematic Entry in Xilinx ISE 4.1i
From: yaot@hotmail.com (Terry)
Date: 8 Feb 2002 11:59:24 -0800
Links: << >>  << T >>  << A >>
Hi

I'm trying to use the schematic entry (ECS) method in ISE 4.1i to
design circuits for the Virtex-II fpga.  But when I go to Project -
New Source to select the ECS, there are no options for ECS, VHDL,
Verilog, etc. in the dialogue box.  So I then attempt to create the
schematic by first opening the ECS window, but I can't upload the
Virtex-II Schematic Library...there is only the XC9500 CPLD library. 
I'm using the standard version of ISE (not the evaluation version, not
WEBPACK) so I don't know what the problem is.  I'd appreciate any
advice on this matter.

Thanks

Terry

Article: 39423
Subject: Re: Xilinx ISE 3.3 upgrade to 4.1
From: "Mike Johnson" <mikej<NOSPAM>freeuk.com>
Date: Fri, 8 Feb 2002 20:14:07 -0000
Links: << >>  << T >>  << A >>
I'm surprised, but Virtex-E speedfiles are indeed still marked preliminary.

the only diferences I spoted between 3.3.8 and 4.1.03 were in Tdh and Tds
(setup / hold for BX & BY inputs on CLB distibuted ram)

release 4.1.03i xc600e speedfile 1.65 2001-11-14
Tdh -585 - -495 , Tds 686 - 958

release 3.3.08i xv600e speedfile 1.60 2001-05-08
Tdh -186 - -96 , Tds 469 - 559

Jui, are you using lots of distributed ram elements by any chance?
I guess in future more (some?) timing slack will have to be allocated to
possible characterisation and process changes.

Regards,
Mike.

<hamish@cloud.net.au> wrote in message
news:3c63d91c$0$18472$afc38c87@news.optusnet.com.au...
> Jui Tan <juitongtanSPAM@yahoo.com> wrote:
> > 2 weeks ago, I decided to upgrade my tools to version 4.1.  After the
> > upgrade, I ran the same design through version 4.1 and got a whole list
of
> > timing violations (some constraints are violated due to gate delays
alone).
> > I called the Xilinx tech hotline, and they said that the timing library
for
> > version 4.1 reflects the characteristics of the latest silicon.  He told
me
>
> Yep. The newer software has newer (hopefully more accurate) timing
> data. The speed files change quite regularly, even between service packs.
>
> > I am sure I am not the only person with this problem.  If you have a
virtexE
> > design in production PAR with ISE 3.3, what have/would you do?
>
> The Virtex-E speed files are still changing. The 4.1i service pack 3
> release has v1.65 of the Virtex-E speed files, and there's some more
> slow downs in those (CLB RAM setup time, from memory). A previous
> version slowed down some block RAM control inputs. The 3.3 service
> pack 8 speed files doubled the block RAM clock-to-out delay.
>
> So you have a Virtex-E design which meets timing in 3.3 and works
> in all of your testing with the devices you have. So do you
> make the effort to get it to meeting timing with the newer speed data?
> Good question. I think of it this way -- the speed files reflect what
> the silicon could be, at worst.
>
> That your design works on the silicon you have unfortunately isn't
> proof that it will work on every part that you ever ship. Theoretically
> Xilinx could actually change the silicon to match pessimistic speed
> files if that would improve yield, product cost etc.
>
> So, I've spent the last week updating some old designs and I'll
> be spending most of next week on it too. Not much fun but necessary.
> (Actually, there is some real design work to be done so we're
> upgrading to the last speed files at the same time -- we don't
> generally re-route designs just for new timing data.)
>
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>



Article: 39424
Subject: Re: CLKDLL x4 problem
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Fri, 8 Feb 2002 20:32:09 -0000
Links: << >>  << T >>  << A >>
Starting from a 10MHz clock, you can use Peter's circuit to double
to 20MHz, then run the faster clock through the DLL.  Still outside
limits, but will almost certainly work on the bench - stick to
25MHz in shipping product.

Phil Connor wrote
> Seriously though a single mention in an entire application note
> dedicated to the DLL (XAPP132) would have been nice.
>
> There is even a helpful section "Design Considerations ...Input Clock"
> which says "The DLL can be used with any commercially available
> quartz crystal oscillator". A bold claim.
>
> Interestingly the Vertex has no lower clock limit, so Xilinx tell
> me. So it seems it can run down to DC.
>
> I would bet that Antonio and I are not the only ones to have slipped
> up here.
>
> Anyone else?






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