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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 151325

Article: 151325
Subject: Re: SRL as a synchroniser
From: Allan Herriman <allanherriman@hotmail.com>
Date: 23 Mar 2011 11:14:52 GMT
Links: << >>  << T >>  << A >>
On Tue, 22 Mar 2011 12:27:10 +0000, Allan Herriman wrote:

> Hi,
> 
> At a client's site I have some legacy VHDL code that is being
> synthesised with Xilinx XST 13.1 with Virtex 6 as a target.
> 
> This code has some clock domain crossing circuits that use two flip
> flops cascaded in the destination clock domain (it's the usual
> synchroniser that you've all seen before).
> 
> This code worked fine in whatever version of XST it was originally
> written for, but with 13.1 I find that these flip flops are being
> replaced by SRL32 primitives, the default inference rule being that
> whenever XST sees two or more flip flops (without a reset and with the
> same control inputs) in series, it replaces them with an SRL.
> 
> Obviously, the XST team thought that this was an appropriate thing to
> do, but anyone with a modicum of experience should know better.
> 
> 
> Question: just how bad are the SRL for this application?  Have they even
> been characterised?
> 
> 
> BTW, there are many possible fixes:
> 
> - Put an attribute (SHREG_something_or_other) on each and every
> synchroniser to disable SRL inference.
> 
> - Disable SRL inference globally (not good).
> 
> - Change the XST setting (SHREG_something_else) to 3 so that chains of 2
> flip flops are left alone.
> 
> - Add a reset (or other control signal that will stop SRL inference) to
> each and every synchroniser in the design.
> 
> - Wait for XST to be fixed (but don't hold your breath).


The relevant attributes are:


SHREG_EXTRACT (yes/no) applies to signals or entities (in HDL source) or 
globally (as an XST option).

SHREG_MIN_SIZE (default of 2) global XST option.  This defines the 
smallest number of flip flops in a chain that will be converted to SRL.

(I consider the default SHREG_MIN_SIZE value of 2 to be low for a target 
that has four flip flops for every SRL, but perhaps it has more to do 
with the routing than the logic.)


The fix I applied to the client's design was to put the SHREG_EXTRACT 
attribute on every synchroniser flip flop.  This required more code 
changes than I would have liked, because many of the flip flops were 
inferred from variables, and XST doesn't allow the attribute to be 
applied to variables, only signals.


The problem was discovered by a co-worker (hi Adrian!) during a review of 
the tool report files.


The long term fix (for us) involves two steps:

1.  Modify the in-house coding standard to require that those attributes 
be used on synchronising flip flops in the HDL source.

2.  Add an automated check of the extracted gate-level netlist that will 
be run at the end of our (fully scripted) build process which will 
identify and warn of SRLs being used inappropriately.


Regards,
Allan

Article: 151326
Subject: Re: Xilinx EDK - max array size
From: Marc Jet <jetmarc@hotmail.com>
Date: Wed, 23 Mar 2011 05:05:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Tobias Baumann wrote:
> So I need some basical information about where I have to find mistakes
> in my program and how I can solve them. And I need information about
> where the limits are.

Your code seems to use too much autovar (stack) memory at runtime.  I
don't know how you found the value of 496.  Maybe your program crashes
for higher values?

Simple C runtime doesn't do stack checking and you can run out of
memory without warning.  You should avoid this.

A good start would be to move the big buffer outside of the function
(possibly with a "static" keyword in front).  This will make it a link
time allocation in BSS section, and the linker will complain if
there's not enough memory available instead of just crash.  Also, you
can consult the linker map file to see how much bigger your buffer
could be.

When your project advances and you really need dynamic buffer
allocation, you can use a real memory allocator for the bigger stuff.
It lets you to handle more memory while the stack requirements remain
small.  It will also tell you when there is not enough memory and your
code can handle that gracefully.

You may find more advice from embedded system programmers.  The
constraints are not always the same as on a desktop system, where
resouces are almost infinite.

Best regards,
Marc

Article: 151327
Subject: Re: pcb&bitstream
From: jay <jay@jayt.org>
Date: Wed, 23 Mar 2011 12:19:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:
> On Mar 19, 6:49 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>>> On Mar 19, 10:48 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
>> 
>> (snip)
>> 
>>>> It was at FPL1999 that someone presented this as a sidenote in a
>>>> presentation about some
>>>> other topic. They said they were able to damage Altera FPGAs by
>>>> instantiating ring counters.
>> 
>> (snip)
>> 
>>> What you remember as a ring counter was probably a ring oscillator
>>> that was used to get a high frequency clock to drive the rest of the
>>> FPGA logic with a high toggle rate.  Without system level
>>> considerations and monitoring the power requirements could easily push
>>> the device into a thermal region that would damage the device.   The
>>> HDL and bitstream itself is perfectly valid, it is the thermal
>>> management that is to blame for the destruction.   The failure points
>>> would likely be wide spread through the device.
>> 
>> The designs that I am interested in have many signals changing
>> on average every other clock cycle, and clocked as fast as I can
>> get the design to run.  I have wondered when that will cause thermal
>> problems, such as requiring a heat sink.
>> 
>>> This failure mode isn't the same as a badly constructed bitstream
>>> violating DRC rules and creating device damage that would be difficult
>>> to detect as it may only exist at a few points within the device.
>> 
>> Well, a small ring oscillator would cause local heating, which
>> may be enough to damage a small portion of the device.
>> 
>>> Recent Xilinx FPGAs with the System Monitor feature (renamed to XADC
>>> in the 7 Series families) have the ability to shutdown the device if
>>> the junction temperature exceeds user defined values.  This can be
>>> used to prevent this type of thermal damage, but it would not be able
>>> to prevent localized damage due to bad bitstreams.
>> 
>> That should work for heating over the whole array, but maybe not
>> good enough for a localized ring oscillator.
>> 
>> Though shouldn't DRC be able to detect ring oscillators?  
>> Is it that hard to do?
>> 
>> -- glen
> 
> It sounds like you have a pretty aggressive design and if there is a
> lot of logic in the design than it would be possible to exceed Tj
> without a heat sink.  The Xilinx XPE (estimator) and XPA (analyzer)
> can help you out with determining the expectated power and thermal
> requirements.  See http://www.xilinx.com/power for more details.
> 
> I wouldn't be worried about a ring oscillator creating any significant
> localized heating in an FPGA to the point that it would damage the
> device.  Ring oscillator circuits are used extensively in the device
> testing and I've never heard of an RMA linked to anything that even
> remotely resembled damage due to localized Tj extremes.
> 
> If you do have ring oscillators in your design you will get some
> warnings in the timing analysis, but otherwise they are permitted as
> there isn't anything wrong with a ring oscillator.
> 
> Ed McGettigan
> --
> Xilinx Inc.

My own testing has shown this. I've been pretty abusive to one particular
S3E with ring oscillators, and it's ticking along just fine.

Article: 151328
Subject: Re: Xilinx EDK - max array size
From: MBodnar <michaelrbodnar@gmail.com>
Date: Wed, 23 Mar 2011 05:45:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 23, 7:05=A0am, Marc Jet <jetm...@hotmail.com> wrote:
> Tobias Baumann wrote:
> > So I need some basical information about where I have to find mistakes
> > in my program and how I can solve them. And I need information about
> > where the limits are.
>
> Your code seems to use too much autovar (stack) memory at runtime. =A0I
> don't know how you found the value of 496. =A0Maybe your program crashes
> for higher values?
>
> Simple C runtime doesn't do stack checking and you can run out of
> memory without warning. =A0You should avoid this.
>
> A good start would be to move the big buffer outside of the function
> (possibly with a "static" keyword in front). =A0This will make it a link
> time allocation in BSS section, and the linker will complain if
> there's not enough memory available instead of just crash. =A0Also, you
> can consult the linker map file to see how much bigger your buffer
> could be.
>
> When your project advances and you really need dynamic buffer
> allocation, you can use a real memory allocator for the bigger stuff.
> It lets you to handle more memory while the stack requirements remain
> small. =A0It will also tell you when there is not enough memory and your
> code can handle that gracefully.
>
> You may find more advice from embedded system programmers. =A0The
> constraints are not always the same as on a desktop system, where
> resouces are almost infinite.
>
> Best regards,
> Marc

Like Marc said, definitely avoid those stack allocations.  In this
embedded environment with little runtime support, it can be hard to
diagnose problems like these (especially as the program gets more
complicated).

Thankfully, as an embedded designer targeting a specific platform for
a specific application, you can pretty much have free reign over the
entire address map.  It's perfectly legal to declare a pointer to a
known region of unused memory (known and unused in the sense that none
of the peripherals are mapped to that address and the code size of the
elf won't clash with it).  Something like:

Xuint8 *buffer =3D 0x04000000;  // just the starting address of the
buffer

Then you can dereference it like an array.  I've used this technique,
and it's easy, but I'm not 100% sure it's the best/safest/etc.

Regards,

MB

Article: 151329
Subject: Re: pcb&bitstream
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 23 Mar 2011 18:53:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
jay <jay@jayt.org> wrote:

(snip, I wrote)
>>> Well, a small ring oscillator would cause local heating, which
>>> may be enough to damage a small portion of the device.

(someone else wrote)
>> I wouldn't be worried about a ring oscillator creating any significant
>> localized heating in an FPGA to the point that it would damage the
>> device.  Ring oscillator circuits are used extensively in the device
>> testing and I've never heard of an RMA linked to anything that even
>> remotely resembled damage due to localized Tj extremes.

(snip)
> My own testing has shown this. I've been pretty abusive to one particular
> S3E with ring oscillators, and it's ticking along just fine.

It seems to me that the smallest is one inverter.  If you do that
with a single CMOS inverter, I believe it just sits at the switch
point dissipating power.  (In the CD4000 days, we were cautioned
not to leave inputs floating, as they can float to the switch
point.)   In an FPGA, the routing delay might be long enough to
allow oscillation.

-- glen

Article: 151330
Subject: Re: pcb&bitstream
From: Gabor <gabor@alacron.com>
Date: Wed, 23 Mar 2011 12:26:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, March 23, 2011 2:53:54 PM UTC-4, glen herrmannsfeldt wrote:
> jay <j...@jayt.org> wrote:
> 
> (snip, I wrote)
> >>> Well, a small ring oscillator would cause local heating, which
> >>> may be enough to damage a small portion of the device.
> 
> (someone else wrote)
> >> I wouldn't be worried about a ring oscillator creating any significant
> >> localized heating in an FPGA to the point that it would damage the
> >> device.  Ring oscillator circuits are used extensively in the device
> >> testing and I've never heard of an RMA linked to anything that even
> >> remotely resembled damage due to localized Tj extremes.
> 
> (snip)
> > My own testing has shown this. I've been pretty abusive to one particular
> > S3E with ring oscillators, and it's ticking along just fine.
> 
> It seems to me that the smallest is one inverter.  If you do that
> with a single CMOS inverter, I believe it just sits at the switch
> point dissipating power.  (In the CD4000 days, we were cautioned
> not to leave inputs floating, as they can float to the switch
> point.)   In an FPGA, the routing delay might be long enough to
> allow oscillation.
> 
> -- glen

In an FPGA you can't get close to the simplicity of
a single inverter.  Even if you consider a LUT programmed
to invert its input, you still have some additional
buffering in the feedback path.  So I wouldn't expect
to be able to reproduce the linear feedback behavior
of an unbuffered CMOS inverter.  It might be too fast
to clock anything useful in the FPGA but a single
looped back "inverter" would probably still oscillate.

-- Gabor

Article: 151331
Subject: Re: pcb&bitstream
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 23 Mar 2011 20:31:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
Gabor <gabor@alacron.com> wrote:

(snip, I wrote) 
>> It seems to me that the smallest is one inverter.  If you do that
>> with a single CMOS inverter, I believe it just sits at the switch
>> point dissipating power.  (In the CD4000 days, we were cautioned
>> not to leave inputs floating, as they can float to the switch
>> point.)   In an FPGA, the routing delay might be long enough to
>> allow oscillation.
 
> In an FPGA you can't get close to the simplicity of
> a single inverter.  Even if you consider a LUT programmed
> to invert its input, you still have some additional
> buffering in the feedback path.  So I wouldn't expect
> to be able to reproduce the linear feedback behavior
> of an unbuffered CMOS inverter.  It might be too fast
> to clock anything useful in the FPGA but a single
> looped back "inverter" would probably still oscillate.

Yes, that is what I thought.  I should have been a little stronger
in my wording, but, not having actually tried it, "probably"
seemed safe to me.   

-- glen

Article: 151332
Subject: Problems connecting with Xilinx Spartan-6 FPGA
From: DaMunky89 <shwankymunky@gmail.com>
Date: Wed, 23 Mar 2011 14:16:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Currently, when trying to download the bitstream to this SP605 board,
I get the following error:

FPGA configuration encountered errors.
Program FPGA failed
   ERROR: Connection to Board Failed
Failed to Open JTAG Cable
    Check the following:
    1. Cable is Connected to the Board and the Board is Powered-ON
    2. On Cable Lock Error, Close the other application using the
cable or Remove Cable Locks using "xclean_cablelock" command
    3. You have specified the correct JTAG settings for cable type and
port.

So basically the SDK is not seeing the board. It's odd, because in my
"Devices and Printers" window it does appear as "Silicon Labs CP210x
USB to UART Bridge (COM3)". Currently it seems that my computer thinks
this connection is a wired mouse. (That's the icon it's showing.)
Earlier it was using the generic "unidentified device" icon, but it
has been unplugged and reattached a couple times since then.

I'm using SDK version 12.3 on a Windows 7 x64 version 6.1.7600 Build
7600.
I tried following the instructions in the included "Getting Started"
pamphlet to ensure the board was hooked up correctly, and basically
when I got to the part where the Xilinx logo is supposed to appear
onscreen I instead get large horizontal green and purple strips,
overlaid with vertical lines in different shades of grey and black. I
get the impression that either the board as a whole, or perhaps just
the adapter piece for the monitor cable is broken.

I am getting a solid green and a solid red "Error" LED in the upper-
right corner of the board. Not sure if these mean anything. Any ideas
as to how I can get this connected and running projects?

Article: 151333
Subject: Re: Problems connecting with Xilinx Spartan-6 FPGA
From: John McCaskill <jhmccaskill@gmail.com>
Date: Wed, 23 Mar 2011 15:23:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 23, 4:16=A0pm, DaMunky89 <shwankymu...@gmail.com> wrote:
> Currently, when trying to download the bitstream to this SP605 board,
> I get the following error:
>
> FPGA configuration encountered errors.
> Program FPGA failed
> =A0 =A0ERROR: Connection to Board Failed
> Failed to Open JTAG Cable
> =A0 =A0 Check the following:
> =A0 =A0 1. Cable is Connected to the Board and the Board is Powered-ON
> =A0 =A0 2. On Cable Lock Error, Close the other application using the
> cable or Remove Cable Locks using "xclean_cablelock" command
> =A0 =A0 3. You have specified the correct JTAG settings for cable type an=
d
> port.
>
> So basically the SDK is not seeing the board. It's odd, because in my
> "Devices and Printers" window it does appear as "Silicon Labs CP210x
> USB to UART Bridge (COM3)". Currently it seems that my computer thinks
> this connection is a wired mouse. (That's the icon it's showing.)
> Earlier it was using the generic "unidentified device" icon, but it
> has been unplugged and reattached a couple times since then.
>
> I'm using SDK version 12.3 on a Windows 7 x64 version 6.1.7600 Build
> 7600.
> I tried following the instructions in the included "Getting Started"
> pamphlet to ensure the board was hooked up correctly, and basically
> when I got to the part where the Xilinx logo is supposed to appear
> onscreen I instead get large horizontal green and purple strips,
> overlaid with vertical lines in different shades of grey and black. I
> get the impression that either the board as a whole, or perhaps just
> the adapter piece for the monitor cable is broken.
>
> I am getting a solid green and a solid red "Error" LED in the upper-
> right corner of the board. Not sure if these mean anything. Any ideas
> as to how I can get this connected and running projects?

The SP605 has two mini USB ports on it. One of them is a USB to serial
port, and that appears to be what you have connected to if you see the
Silicon Labs part. The other one is the USB to JTAG port.  Try
connecting to that one, and see if the "Failed to Open JTAG Cable"
error message goes away.

Regards,

John McCaskill
www.FasterTechnology.com

Article: 151334
Subject: Re: SRL as a synchroniser
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Thu, 24 Mar 2011 06:27:14 -0500
Links: << >>  << T >>  << A >>
>On Tue, 22 Mar 2011 12:27:10 +0000, Allan Herriman wrote:
[elided]
>
>The long term fix (for us) involves two steps:
>
>1.  Modify the in-house coding standard to require that those attributes 
>be used on synchronising flip flops in the HDL source.
>
>2.  Add an automated check of the extracted gate-level netlist that will 
>be run at the end of our (fully scripted) build process which will 
>identify and warn of SRLs being used inappropriately.
>
>
>Regards,
>Allan

As I am concerned that this is happening to our designs, I had a trawl on
the Xilinx web-site, and found the following:
http://www.xilinx.com/support/answers/35967.htm

Summary: While SHREG_EXTRACT="no" stops XST, it doesn't stop MAP doing it!

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 151335
Subject: Re: Cortex M1 and GUI
From: yjhgj <user@compgroups.net/>
Date: Thu, 24 Mar 2011 08:53:10 -0500
Links: << >>  << T >>  << A >>
Oh hell ya



Article: 151336
Subject: Re: pcb&bitstream
From: mac <alex.colvin@valley.net>
Date: Thu, 24 Mar 2011 14:03:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
I no langer have the piece, but I used to keep a X. Chip that had holes
blown through the lid when it got reloaded from a bsd ROM. My understanding
is that most chips now verify a checksum on loading. 

-- 
mac the naïf

Article: 151337
Subject: Re: SRL as a synchroniser
From: Gabor <gabor@alacron.com>
Date: Thu, 24 Mar 2011 07:19:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, March 24, 2011 7:27:14 AM UTC-4, RCIngham wrote:
> >On Tue, 22 Mar 2011 12:27:10 +0000, Allan Herriman wrote:
> [elided]
> >
> >The long term fix (for us) involves two steps:
> >
> >1.  Modify the in-house coding standard to require that those attributes 
> >be used on synchronising flip flops in the HDL source.
> >
> >2.  Add an automated check of the extracted gate-level netlist that will 
> >be run at the end of our (fully scripted) build process which will 
> >identify and warn of SRLs being used inappropriately.
> >
> >
> >Regards,
> >Allan
> 
> As I am concerned that this is happening to our designs, I had a trawl on
> the Xilinx web-site, and found the following:
> http://www.xilinx.com/support/answers/35967.htm
> 
> Summary: While SHREG_EXTRACT="no" stops XST, it doesn't stop MAP doing it!
> 
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

My code generally has a reset term for everything
whether it needs one or not.  I only leave out the
reset if I explicitly want to generate SRL-based
shift registers.  Neither XST nor Map can use
an SRL when the register needs a reset.

-- Gabor

Article: 151338
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: "PovTruffe" <PovTache@gaga.invalid>
Date: Thu, 24 Mar 2011 16:13:26 +0100
Links: << >>  << T >>  << A >>
"Joel Williams" <nospamwhydontyoublogaboutit@nospamgmail.com> a écrit :
>
> It all depends on whether this is a PCB and circuit design exercise or an FPGA development exercise.

Both.

> Trying to get high speed designs working on two layer boards can be a complete waste of time when things just plain 
> don't work and you have to start again. A four layer board is actually considerably easier to lay out for complicated 
> designs and if you're not in much of a hurry, some of the hobbyist orientated manufacturing services are incredibly 
> cheap. For example, http://dorkbotpdx.org/wiki/pcb_order charge $10 per square inch with four layers, and that's for 
> three boards. I'd seriously consider doing this even if I was using the PQ208 package.

$10 - 4 layers ! Why did not you tell me this before   ;-))
I thought prices were in the hundreds.

> If you're interested in soldering BGA packages at home, have a look at this project: 
> http://danstrother.com/2011/01/16/spartan-6-bga-test-board/ . It hasn't yet been built, but if the reflow oven method 
> works it would be very easy to adapt this (open source) design for your uses, either by adding a simple VGA output or 
> an HDMI buffer.

Great link, this project is very interesting with many things to learn.

I did not realize Spartan-6 had such powerful features (like a mini Virtex...) for
the same price I would have paid for a Spartan-3E (6 input LUTs, hard DRAM
controller, etc).

After some research it seems BGA soldering is not as out of reach as I thought.
The hot plate method is very simple and seems to give very good results.
There are also refusion ovens on eBay under $300.

At the end, I changed my mind and decided to go "BGA / 4 layers / Spartan-6"
Many thanks to all who gave their usefull advice.



Article: 151339
Subject: Re: RAM - DIMM vs SO-DIMM: price vs. (hardware & software) ease of use
From: "PovTruffe" <PovTache@gaga.invalid>
Date: Thu, 24 Mar 2011 16:31:36 +0100
Links: << >>  << T >>  << A >>
"Gabor" <gabor@alacron.com> a écrit :
> On Monday, March 21, 2011 7:08:32 PM UTC-4, PovTruffe wrote:
> You should be worried about pin inductance in the PQ208.  In
> my experience these packages are not suitable for high-speed I/O.

OK

> The problem with starting with a flawed design just
> to "finish this year" is that your board won't do what
> you wanted, and then you could be more discouraged.

It seems I would better submit the project here before doing anything...

> If you really want to use the large PQ package, you need to
> resign yourself to using low slew-rate I/O because of the
> horrendous ground-bounce in those packages (even when
> using additional "virtual ground" pins).

I did not know the PQ packages were that bad.

> Single data-rate Mobile SDRAM may be your best choice
> because it can run at low clock rates and use only
> LVCMOS levels.  You won't find a pre-made MIG core
> for it, though as you might for DDR memory types.
> Writing your own Mobile DDR (also called lpDDR)
> controller would be a good exercise as well.  I
> have used single data rate memories for a number
> of video products including UXGA resolution video
> capture.  You can realize any data rate you need
> by making the memory wide enough.  It doesn't even
> have to be a power of two width.  The UXGA capture
> board uses 48-bit wide memory which matches the
> RGB 2-pixel-wide data stream.
>
> Video buffering is an easier design than a general
> purpose memory controller for fully random access.
> My controllers usually have a minimum transfer of
> one burst to each of the banks in the memory.  The
> bank overlap allows me to "bury" the precharge and
> activate time and keep the interface streaming at
> almost 100% of the peak rate.
>
> Good luck on your projects.

Thank you

> -- Gabor



Article: 151340
Subject: Re: Alternative To Altera's Cyclone III Starter Board
From: "Abby Brown" <abbybrown@charter.net>
Date: Fri, 25 Mar 2011 14:34:22 -0400
Links: << >>  << T >>  << A >>

"rickman" <gnuarm@gmail.com> wrote in message 
news:c37781b2-2437-4dd1-a584-53b710133ba6@w7g2000pre.googlegroups.com...
On Mar 14, 6:38 pm, "Abby Brown" <abbybr...@charter.net> wrote:
> Hi,
>
> Does someone produce a cheaper and simpler substitute for
> Altera's Cyclone III starter board? It needs to connect to a
> laptop to download configuration and test cases and upload
> results (ICT). A driver that connects to Windows .Net would be
> ideal.
>
> Thanks,
> Gary

: I have to say I am pretty ignorant of .NET other than this was
: Microsoft's response when Sun told them to stop tinkering with 
JAVA.
: What would the driver accomplish and how would you use it?

: Rick

It obviates a logic simulator (Altera's free one is limited). 
Use the actual device instead.  I can automate test cases with a 
C# program.  I used to write logic simulators for a living and 
hate the damn things.

Gary



Article: 151341
Subject: Measuring the delay between two rising edges in modelsim simulation
From: Pratap <pratap.iisc@gmail.com>
Date: Fri, 25 Mar 2011 17:00:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I want to measure the delay between two rising edges in modelsim
simulation. There are commands in spice like tools where the .measure
statements are used to measure the delays. But I am not able to find
such method, where I would fire such command to print the delays into
a text file through a tcl script.
Looking forward to some positive suggestions,
Thanks in advance,
Pratap

Article: 151342
Subject: How to take signals fed to EXT_CLK_P and EXT_CLK_N SMA connectors
From: Pratap <pratap.iisc@gmail.com>
Date: Fri, 25 Mar 2011 17:59:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I want to delay a signal precisely by taking out the signal from the
FPGA so that it can be fed to another chip which can control the delay
through that. I want to feed this delayed signal back to the FPGA by
inputting that signal through another pin on the Xilinx Virtex II Pro
board. I am using the EXT_CLK_P and EXT_CLK_N pins for inputting the
desired signals. The signal to be delayed is fed to the pin EXT_CLK_P
by installing SMA connectors at those points. I have also installed
separate connectors at EXT_CLK_N, MGT_TXP and MGT_TXN. But I am not
able to route the signals as I get the following error while mapping.

Using target part "2vp30ff896-7".
Mapping design into LUTs...
Running directed packing...
ERROR:Pack:1107 - Unable to combine the following symbols into a
single IOB
   component:
   	BUF symbol "inp_for_TI_chip_OBUF" (Output Signal =
inp_for_TI_chip)
   	PAD symbol "inp_for_TI_chip" (Pad Signal = inp_for_TI_chip)
   Each of the following constraints specifies an illegal physical
site for a
   component of type IOB:
   	Symbol "inp_for_TI_chip" (LOC=A6)
   Please correct the constraints accordingly.

The motivation behind using the SMA connectors for the connectivity is
to have good signal shape of the input square wave signals, by which
the delays can be precisely maintained. I have also tried connect the
output from the FPGA pin for the external delay controller and also
the input signal from the controller to the chip through other Non-SMA
type pins in J5 or J6 connectors. But even doing that doesn't solve my
purpose, as I don't get any thing signal reaching at those points.
Surprisingly, only when I connect those signals intended to be fed to
the external delay controller chip to the externally non-available
pins MGT_CLK_P and MGT_CLK_N, I get all the signals toggling, but my
purpose of routing the signals through the external chip is not
solved.
Can anybody help me understand, why this connection to MGT_CLK_P and
MGT_CLK_N for the stuff to work and how those are hooked upto the
system? How can I solve my purpose of taking the signals fed to
EXT_CLK_P and EXT_CLK_N SMA connectors from the Virtex II Pro board
and route it through another chip.
Looking forward to some helpful suggestions,
Thanks in advance,
Pratap

Article: 151343
Subject: Re: Measuring the delay between two rising edges in modelsim
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 25 Mar 2011 19:26:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 8:00=A0pm, Pratap <pratap.i...@gmail.com> wrote:
> Hi,
> I want to measure the delay between two rising edges in modelsim
> simulation. There are commands in spice like tools where the .measure
> statements are used to measure the delays. But I am not able to find
> such method, where I would fire such command to print the delays into
> a text file through a tcl script.
> Looking forward to some positive suggestions,
> Thanks in advance,
> Pratap

Presuming that you know VHDL or Verilog, then write a handful of lines
of code and write the file from the simulation itself.

KJ

Article: 151344
Subject: Re: How to take signals fed to EXT_CLK_P and EXT_CLK_N SMA connectors
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Fri, 25 Mar 2011 21:04:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 5:59=A0pm, Pratap <pratap.i...@gmail.com> wrote:
> Hi,
> I want to delay a signal precisely by taking out the signal from the
> FPGA so that it can be fed to another chip which can control the delay
> through that. I want to feed this delayed signal back to the FPGA by
> inputting that signal through another pin on the Xilinx Virtex II Pro
> board. I am using the EXT_CLK_P and EXT_CLK_N pins for inputting the
> desired signals. The signal to be delayed is fed to the pin EXT_CLK_P
> by installing SMA connectors at those points. I have also installed
> separate connectors at EXT_CLK_N, MGT_TXP and MGT_TXN. But I am not
> able to route the signals as I get the following error while mapping.
>
> Using target part "2vp30ff896-7".
> Mapping design into LUTs...
> Running directed packing...
> ERROR:Pack:1107 - Unable to combine the following symbols into a
> single IOB
> =A0 =A0component:
> =A0 =A0 =A0 =A0 BUF symbol "inp_for_TI_chip_OBUF" (Output Signal =3D
> inp_for_TI_chip)
> =A0 =A0 =A0 =A0 PAD symbol "inp_for_TI_chip" (Pad Signal =3D inp_for_TI_c=
hip)
> =A0 =A0Each of the following constraints specifies an illegal physical
> site for a
> =A0 =A0component of type IOB:
> =A0 =A0 =A0 =A0 Symbol "inp_for_TI_chip" (LOC=3DA6)
> =A0 =A0Please correct the constraints accordingly.
>
> The motivation behind using the SMA connectors for the connectivity is
> to have good signal shape of the input square wave signals, by which
> the delays can be precisely maintained. I have also tried connect the
> output from the FPGA pin for the external delay controller and also
> the input signal from the controller to the chip through other Non-SMA
> type pins in J5 or J6 connectors. But even doing that doesn't solve my
> purpose, as I don't get any thing signal reaching at those points.
> Surprisingly, only when I connect those signals intended to be fed to
> the external delay controller chip to the externally non-available
> pins MGT_CLK_P and MGT_CLK_N, I get all the signals toggling, but my
> purpose of routing the signals through the external chip is not
> solved.
> Can anybody help me understand, why this connection to MGT_CLK_P and
> MGT_CLK_N for the stuff to work and how those are hooked upto the
> system? How can I solve my purpose of taking the signals fed to
> EXT_CLK_P and EXT_CLK_N SMA connectors from the Virtex II Pro board
> and route it through another chip.
> Looking forward to some helpful suggestions,
> Thanks in advance,
> Pratap

The MGT TXP/TXN/RXP/RXN pins are dedicated pins that can only be used
by the MGTs.  In the Virtex-II Pro FPGA family the MGT reference clock
pins were normal I/Os that had extra dedicated routing to the MGTs.

Are you using a Xilinx board?  If so which one is it?

What are the IO location constraints that you are using for the output
and input paths?

Ed McGettigan
--
Xilinx Inc.

Article: 151345
Subject: Re: Measuring the delay between two rising edges in modelsim
From: Pratap <pratap.iisc@gmail.com>
Date: Fri, 25 Mar 2011 21:18:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 7:26=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
> On Mar 25, 8:00=A0pm, Pratap <pratap.i...@gmail.com> wrote:
>
> > Hi,
> > I want to measure the delay between two rising edges in modelsim
> > simulation. There are commands in spice like tools where the .measure
> > statements are used to measure the delays. But I am not able to find
> > such method, where I would fire such command to print the delays into
> > a text file through a tcl script.
> > Looking forward to some positive suggestions,
> > Thanks in advance,
> > Pratap
>
> Presuming that you know VHDL or Verilog, then write a handful of lines
> of code and write the file from the simulation itself.
>
> KJ

Can you please point me to such examples? I know VHDL...but haven't
ever tried writing to a file.

Article: 151346
Subject: Re: Measuring the delay between two rising edges in modelsim simulation
From: Alexander Sotnikov <alex.sotnikov@qip.ru>
Date: Sat, 26 Mar 2011 09:58:24 +0300
Links: << >>  << T >>  << A >>
On 3/26/2011 7:18 AM, Pratap wrote:
> On Mar 26, 7:26 am, KJ<kkjenni...@sbcglobal.net>  wrote:
>> On Mar 25, 8:00 pm, Pratap<pratap.i...@gmail.com>  wrote:
>>
>>> Hi,
>>> I want to measure the delay between two rising edges in modelsim
>>> simulation. There are commands in spice like tools where the .measure
>>> statements are used to measure the delays. But I am not able to find
>>> such method, where I would fire such command to print the delays into
>>> a text file through a tcl script.
>>> Looking forward to some positive suggestions,
>>> Thanks in advance,
>>> Pratap
>>
>> Presuming that you know VHDL or Verilog, then write a handful of lines
>> of code and write the file from the simulation itself.
>>
>> KJ
>
> Can you please point me to such examples? I know VHDL...but haven't
> ever tried writing to a file.

It's just one of numerous examples that Google returns for the search 
string text io vhdl:
http://eesun.free.fr/DOC/vhdlref/refguide/language_overview/test_benches/reading_and_writing_files_with_text_i_o.htm

--
Alexander

Article: 151347
Subject: Re: Measuring the delay between two rising edges in modelsim simulation through command/tcl script and writing them to a file.
From: Jonathan Bromley <spam@oxfordbromley.plus.com>
Date: Sat, 26 Mar 2011 13:00:00 +0000
Links: << >>  << T >>  << A >>
On Fri, 25 Mar 2011 17:00:34 -0700 (PDT), Pratap wrote:

>I want to measure the delay between two rising
> edges in modelsim simulation. 

It really depends what you mean by "measure".

In the waveform viewer you can add a second cursor, 
put your two cursors on the edges of interest and
read off the time difference in the cursor area of
the wave viewer.

In VHDL or Verilog you can, as KJ said, easily write
a piece of testbench code that waits for the first 
edge, takes a copy of the current time in a variable, 
waits for the second edge and then reports the 
difference.  In VHDL it would look something 
like this:

  MeasureTime: process
    variable rise_A_time: time;
    variable difference : time;
  begin
    wait until rising_edge(sigA);
    rise_A_time := now;
    wait until rising_edge(sigB);
    difference := now - rise_A_time;
    report "A-to-B time = " & time'image(difference);
    wait;
  end process;

If you remove the final "wait" statement, you will
get repeated reports; with the "wait" you get only
the first one.  

Similarly in Verilog:

  initial begin : MeasureTime
    real rise_A_time;
    real difference;
    @(posedge sig_A) rise_A_time = $realtime;
    @(posedge sig_B) difference = $realtime - rise_A_time;
    $display("At time %t: A-to-B time = %t", 
                      $realtime, difference);
  end

and replace the "initial" with "always" if you want 
the measurement to repeat.  Learn about the $timeformat
system function in Verilog to get pretty time displays.

You could also do it in Tcl, in a simulator script,
using signal breakpoints to trigger some Tcl code
on the edges of the two signals.  This, of course,
will be simulator-specific.

I guess you can see that writing it in Verilog or 
VHDL code provides many opportunities for doing
much cleverer measurements, such as average or
cumulative values, jitter measurements, ratio
measurements... it's limited only by your 
imagination.
-- 
Jonathan Bromley

Article: 151348
Subject: Re: How to take signals fed to EXT_CLK_P and EXT_CLK_N SMA connectors
From: Pratap <pratap.iisc@gmail.com>
Date: Sat, 26 Mar 2011 07:53:50 -0700 (PDT)
Links: << >>  << T >>  << A >>

> The MGT TXP/TXN/RXP/RXN pins are dedicated pins that can only be used
> by the MGTs. =A0In the Virtex-II Pro FPGA family the MGT reference clock
> pins were normal I/Os that had extra dedicated routing to the MGTs.
>
> Are you using a Xilinx board? =A0If so which one is it?
>
> What are the IO location constraints that you are using for the output
> and input paths?
>
> Ed McGettigan
> --
> Xilinx Inc.

Hello,
I am using the Virtex II Pro development board for my project.
I am pasting all the IO constraints written to the ucf file.
The signals to take out and then feed in are "inp_for_TI_chip" and
"op_from_TI_chip" respectively.

NET "reset_in" LOC =3D "AH1" | IOSTANDARD =3D LVCMOS25;
#LEFT P/B

NET "clk_in" LOC =3D "G15" | IOSTANDARD =3D LVCMOS25;
#EXTERNAL_CLOCK_P

NET "samp_clk" LOC =3D "F15" | IOSTANDARD =3D LVCMOS25;
#EXTERNAL_CLOCK_N

NET "op_from_TI_chip"  LOC =3D "A6" | IOSTANDARD =3D LVCMOS25;
#MGT_TXP

NET "inp_for_TI_chip"  LOC =3D "A7" | IOSTANDARD =3D LVCMOS25 | SLEW =3D
FAST | DRIVE =3D 8 ;
#MGT_TXN

NET "ti_delay_chip_cntl"  LOC =3D "R9" | IOSTANDARD =3D LVCMOS25 | SLEW =3D
FAST | DRIVE =3D 8 ;
#J5-11

NET "dir_fine_delay"  LOC =3D "P1" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAS=
T
| DRIVE =3D 8 ;
#J5-15

NET "board_in1"  LOC =3D "AB1" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST |
DRIVE =3D 8 ;
#J6-27

NET "board_in2"  LOC =3D "W8" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST |
DRIVE =3D 8 ;
#J6-35

NET "cleaned_clk1"  LOC =3D "R3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST =
|
DRIVE =3D 8 ;
#J5-31

NET "cleaned_clk2"  LOC =3D "U3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST =
|
DRIVE =3D 8 ;
#J5-39

NET "status(3)" LOC =3D "AC4" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW |
DRIVE =3D 12 ;
NET "status(2)" LOC =3D "AC3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW |
DRIVE =3D 12 ;
NET "status(1)" LOC =3D "AA6" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW |
DRIVE =3D 12 ;
NET "status(0)" LOC =3D "AA5" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW |
DRIVE =3D 12 ;


Thanks,
Pratap

Article: 151349
Subject: Re: How to take signals fed to EXT_CLK_P and EXT_CLK_N SMA connectors
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Sat, 26 Mar 2011 17:32:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 26, 7:53=A0am, Pratap <pratap.i...@gmail.com> wrote:
> > The MGT TXP/TXN/RXP/RXN pins are dedicated pins that can only be used
> > by the MGTs. =A0In the Virtex-II Pro FPGA family the MGT reference cloc=
k
> > pins were normal I/Os that had extra dedicated routing to the MGTs.
>
> > Are you using a Xilinx board? =A0If so which one is it?
>
> > What are the IO location constraints that you are using for the output
> > and input paths?
>
> > Ed McGettigan
> > --
> > Xilinx Inc.
>
> Hello,
> I am using the Virtex II Pro development board for my project.
> I am pasting all the IO constraints written to the ucf file.
> The signals to take out and then feed in are "inp_for_TI_chip" and
> "op_from_TI_chip" respectively.
>
> NET "reset_in" LOC =3D "AH1" | IOSTANDARD =3D LVCMOS25;
> #LEFT P/B
>
> NET "clk_in" LOC =3D "G15" | IOSTANDARD =3D LVCMOS25;
> #EXTERNAL_CLOCK_P
>
> NET "samp_clk" LOC =3D "F15" | IOSTANDARD =3D LVCMOS25;
> #EXTERNAL_CLOCK_N
>
> NET "op_from_TI_chip" =A0LOC =3D "A6" | IOSTANDARD =3D LVCMOS25;
> #MGT_TXP
>
> NET "inp_for_TI_chip" =A0LOC =3D "A7" | IOSTANDARD =3D LVCMOS25 | SLEW =
=3D
> FAST | DRIVE =3D 8 ;
> #MGT_TXN
>
> NET "ti_delay_chip_cntl" =A0LOC =3D "R9" | IOSTANDARD =3D LVCMOS25 | SLEW=
 =3D
> FAST | DRIVE =3D 8 ;
> #J5-11
>
> NET "dir_fine_delay" =A0LOC =3D "P1" | IOSTANDARD =3D LVCMOS25 | SLEW =3D=
 FAST
> | DRIVE =3D 8 ;
> #J5-15
>
> NET "board_in1" =A0LOC =3D "AB1" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAS=
T |
> DRIVE =3D 8 ;
> #J6-27
>
> NET "board_in2" =A0LOC =3D "W8" | IOSTANDARD =3D LVCMOS25 | SLEW =3D FAST=
 |
> DRIVE =3D 8 ;
> #J6-35
>
> NET "cleaned_clk1" =A0LOC =3D "R3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D F=
AST |
> DRIVE =3D 8 ;
> #J5-31
>
> NET "cleaned_clk2" =A0LOC =3D "U3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D F=
AST |
> DRIVE =3D 8 ;
> #J5-39
>
> NET "status(3)" LOC =3D "AC4" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW |
> DRIVE =3D 12 ;
> NET "status(2)" LOC =3D "AC3" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW |
> DRIVE =3D 12 ;
> NET "status(1)" LOC =3D "AA6" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW |
> DRIVE =3D 12 ;
> NET "status(0)" LOC =3D "AA5" | IOSTANDARD =3D LVCMOS25 | SLEW =3D SLOW |
> DRIVE =3D 12 ;
>
> Thanks,
> Pratap

> I am using the Virtex II Pro development board for my project.

This is about as useful as saying that your computer has an Intel ATX
motherboard.  Who made the board, and what is the model number?

Ed McGettigan
--
Xilinx Inc.



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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