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 128650

Article: 128650
Subject: Keeping Xilinx tool from Optimizing out Debugging signals
From: "M. Hamed" <mhs000@gmail.com>
Date: Fri, 1 Feb 2008 10:56:50 -0800 (PST)
Links: << >>  << T >>  << A >>
There is a signal that I need to trigger Chipscope on it for debugging
purposes. However, after synthesis the signal is optimized out since
it's not driving anything (of course it will be driving Chipscope
block but that happens after synthesis). Searching this group I found
some recommend using the KEEP attribute. Is this a recommended
practice? Are there any problems with that approach, since I know this
is not that actual purpose of the KEEP attribute.

Thank you.

Article: 128651
Subject: Re: Active-HDL 7.3 vs Modelsim 6.3d-PE (for Verilog/Systemverilog)
From: Duane Clark <junkmail@junkmail.com>
Date: Fri, 01 Feb 2008 10:57:33 -0800
Links: << >>  << T >>  << A >>
talkb wrote:
> 
> b) Modelsim/PE's Systemverilog (Design) support is more robust than 
> ActiveHDL's. Just about everything I tried worked properly.
> Active-HDL 7.3 has a bunch of rough-edges.  String types don't work
> properly with some standard system-tasks ($swrite, $sformat) -- there
> is no package/endpackage support (maybe that's in the full/commercial
> version?)  And minor quirks in the Systemverilog preprocessor 
> (string-concatenation doesn't trim whitespace: `define(  myword     )
> `" blah myword blah `"
> 

It has been my experience that Aldec is fairly responsive to actual bug 
reports.

Article: 128652
Subject: Re: Keeping Xilinx tool from Optimizing out Debugging signals
From: austin <austin@xilinx.com>
Date: Fri, 01 Feb 2008 11:13:35 -0800
Links: << >>  << T >>  << A >>
http://www.xilinx.com/publications/magazines/dsp_01/xc_pdf/p46-49_dsp-digitalvsa.pdf

That is what is recommended, yes,

Austin

Article: 128653
Subject: Re: Low Pin Count (LPC) bus code available?
From: "TC" <noone@nowhere.com>
Date: Fri, 1 Feb 2008 14:54:13 -0500
Links: << >>  << T >>  << A >>

"johnp" <johnp3+nospam@probo.com> wrote in message 
news:eed75145-9683-4ad2-993c-56d256052f4f@i12g2000prf.googlegroups.com...
> I'm working on a Low Pin Count (LPC) bus interface and would like to
> double check my design with an existing implementation.  Does anyone
> have an existing design they could share?  Verilog source would be
> great.
>
> The LPC bus is a protocol developed by Intel to supplant the ISA bus.
>
> Thanks!
>
> John Providenza

What kind of LPC interface are you implementing (slave, master, dma)?

TC 


Article: 128654
Subject: Re: Low Pin Count (LPC) bus code available?
From: johnp <johnp3+nospam@probo.com>
Date: Fri, 1 Feb 2008 11:57:08 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 1, 11:54 am, "TC" <no...@nowhere.com> wrote:
> "johnp" <johnp3+nos...@probo.com> wrote in message
>
> news:eed75145-9683-4ad2-993c-56d256052f4f@i12g2000prf.googlegroups.com...
>
> > I'm working on a Low Pin Count (LPC) bus interface and would like to
> > double check my design with an existing implementation.  Does anyone
> > have an existing design they could share?  Verilog source would be
> > great.
>
> > The LPC bus is a protocol developed by Intel to supplant the ISA bus.
>
> > Thanks!
>
> > John Providenza
>
> What kind of LPC interface are you implementing (slave, master, dma)?
>
> TC

I'm working on both master & slave (no DMA support).  I found a VHDL
module
yesterday in OpenCores, I've converted it to Verilog and fixed some
bugs in
it as well.  It seems to be doing the job for me at this point.

John P

Article: 128655
Subject: Re: Keeping Xilinx tool from Optimizing out Debugging signals
From: "M. Hamed" <mhs000@gmail.com>
Date: Fri, 1 Feb 2008 12:49:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 1, 12:13 pm, austin <aus...@xilinx.com> wrote:
> http://www.xilinx.com/publications/magazines/dsp_01/xc_pdf/p46-49_dsp...
>
> That is what is recommended, yes,
>
> Austin

Thanks. Works as advertised :-)

Article: 128656
Subject: Re: Design security for pre-Virtex2 parts ?
From: Marlboro <ccon67@netscape.net>
Date: Fri, 1 Feb 2008 13:20:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 31, 1:40=A0pm, j...@amontec.com wrote:
> On Jan 31, 5:21 pm, Marlboro <cco...@netscape.net> wrote:
>
> > Hi all,
>
> > Has anyone ever tried to improve the security for the old Xilinx FPGA
> > devices, which doesn't have the 3-DES encryption? =A0If so what's the
> > feasible approach ? =A0So far I have no clue
>
> > TIA,
>
> We have used this great solution :http://www.maxim-ic.com/appnotes.cfm/an_=
pk/3826
>
> This is a generic solution, not dedicated to any FPGA maker !
>
> Regards,
> Laurent
> =A0http://www.amontec.com


Thanks all for inputs, now at least I have some clues

In summary, the idea is having a another "host device" either using a
CoolRunner or PicoBlaze within the FPGA itself.  The host then
determines whether or not continue to load the real design (by
correctly decode something)

And yet, I agree nothing is absolute safe but at least with the above
approaches it does increase the secure factor



Article: 128657
Subject: Re: Why use small resistor for Vcco voltage regulator
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 02 Feb 2008 10:21:41 +1300
Links: << >>  << T >>  << A >>
Bas Laarhoven wrote:

> Symon wrote:
> 
>> "jasonL" <junsong.liao@gmail.com> wrote in message 
>> news:17c5da4a-f6d9-4891-be9c-c7b8152e3fbd@s37g2000prg.googlegroups.com...
>>
>>> My question is why in Xilinx application notes XAPP457 using such a
>>> small resistors? Is it better to use 22.6K and 38.3K resistors when
>>> the power consumed by resistors and the current bypass  are much small?
>>
>>
>> Hi Jason,
>> It's because the app. note probably has a mistake. The values given 
>> will work, I guess, as they are less than 250k, but I would use 22.6k 
>> and 38.3k. You should email Eric, the XAPP author, and see what he 
>> says. You can find his email address in the C.A.F archive somewhere.
>> Cheers, Syms.
>>
>>
> 
>  From the appnote:
> 
> "Careful inspection of the original design reveals that the impedance of 
> the feedback network is atypically low. Even with zero load, 
> approximately 50 mA is lost through the feedback network.
> At first, this loss seems undesirable, but it serves an important 
> purpose." << Full explanation follows >>

50mA does not stack up, but checking I see the OP has made an error.

The values quoted in XAPP457 are NOT K, but 22.6 and 38.3 OHMS!.

I'd call that an atypical app-note design choice:
* It commits to 150mW of heating, in what are voltage divider
components.
* It means that later change of the 50mA level, requires change of TWO
components that also determine the Vcc.
* If someone removes the ADJ regulator, and drops in a 3.3V one, they 
may completely miss the LOAD element of that divider.


Such casual addition of 50mA of base load, reflects on some of todays
FPGAs current consumption.....

-jg



Article: 128658
Subject: Re: Why use small resistor for Vcco voltage regulator
From: "Eric Crabill" <eric.crabill@xilinx.com>
Date: Fri, 1 Feb 2008 15:22:27 -0800
Links: << >>  << T >>  << A >>
Hello,

The resistor selection is intentional.  In this application, it is desirable 
to shunt 50 mA directly to ground.  You can do that by adding a third 
resistor, or by sizing the voltage divider to accomplish the same effect. 
This "wasted" current prevents the regulator output current from dropping to 
zero when there is a lot of overshoot.  If you are interested in reading 
more about it, the application note XAPP457 does contain a discussion on 
this topic.

Also, if you can somehow guarantee other components powered by VCCO will 
always be drawing some minimum current, you can subtract that from the 50 mA 
and size the voltage divider to be less leaky...

Eric

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message 
news:47a38ce3$1@clear.net.nz...
> Bas Laarhoven wrote:
>
>> Symon wrote:
>>
>>> "jasonL" <junsong.liao@gmail.com> wrote in message 
>>> news:17c5da4a-f6d9-4891-be9c-c7b8152e3fbd@s37g2000prg.googlegroups.com...
>>>
>>>> My question is why in Xilinx application notes XAPP457 using such a
>>>> small resistors? Is it better to use 22.6K and 38.3K resistors when
>>>> the power consumed by resistors and the current bypass  are much small?
>>>
>>>
>>> Hi Jason,
>>> It's because the app. note probably has a mistake. The values given will 
>>> work, I guess, as they are less than 250k, but I would use 22.6k and 
>>> 38.3k. You should email Eric, the XAPP author, and see what he says. You 
>>> can find his email address in the C.A.F archive somewhere.
>>> Cheers, Syms.
>>>
>>>
>>
>>  From the appnote:
>>
>> "Careful inspection of the original design reveals that the impedance of 
>> the feedback network is atypically low. Even with zero load, 
>> approximately 50 mA is lost through the feedback network.
>> At first, this loss seems undesirable, but it serves an important 
>> purpose." << Full explanation follows >>
>
> 50mA does not stack up, but checking I see the OP has made an error.
>
> The values quoted in XAPP457 are NOT K, but 22.6 and 38.3 OHMS!.
>
> I'd call that an atypical app-note design choice:
> * It commits to 150mW of heating, in what are voltage divider
> components.
> * It means that later change of the 50mA level, requires change of TWO
> components that also determine the Vcc.
> * If someone removes the ADJ regulator, and drops in a 3.3V one, they may 
> completely miss the LOAD element of that divider.
>
>
> Such casual addition of 50mA of base load, reflects on some of todays
> FPGAs current consumption.....
>
> -jg 



Article: 128659
Subject: Re: Fixedpoint Multiply/Accumulate in DSP48
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Fri, 1 Feb 2008 15:28:11 -0800 (PST)
Links: << >>  << T >>  << A >>
I don't want to do
P = a*b + c + p
I just want
P = a*b* + c

I can't add C in the MSB tile, because the Z mux is used by PCIN.
I can add C in the lower tile but I can't reach the full dynamic of
the multipliers
result because only 30 bits will end up in the upper tile.
6 extra bits would allow me to add with the same dynamic as the
multiplier result
and 17 extra bits would allow me to add up the full P outputs dynamic.

Does the Virtex-5 DSP slice also resolve the MUX bottleneck?

Kolja



On 30 Jan., 00:39, Kevin Neilson <kevin_neil...@removethiscomcast.net>
wrote:
> comp.arch.fpga wrote:
> > On 28 Jan., 23:43, Kevin Neilson <kevin_neil...@removethiscomcast.net>
> > wrote:
> >> comp.arch.fpga wrote:
> >>> Hi,
> >>> am a little confused as far as the capabilities of the DSP48 go.
> >>> I would like to implement a 18x35 MACC in (hopefully) only two DSP48.
> >>> The 18 bit coefficient is a 0.18 fixed point number. I.e. what I
> >>> really want
> >>> to implement is
> >>> ((A18 x B36)>>17)+C48
> >>> Apparently I overlooked that the DSP48 slice only allows for common C
> >>> inputs
> >>> which means that I can not split C appropriatly accross the two
> >>> adders.
> >>> What am I missing? Do I really need to implement the adder in LUTs?
> >>> Kolja Sulimma
> >> Kolja,
> >> You can easily make an 18x85 multiplier with two DSP48s (see fig 1-20 of
> >>  http://www.xilinx.com/bvdocs/userguides/ug073.pdf) but to do an
> >> accumulation you will have to add a third DSP48, using it only as an
> >> accumulator.  (I wouldn't do this in fabric.  See fig. 5-2 of the same
> >> doc to see the concept used in a semiparallel FIR.)  You could do it in
> >> two DSP48s if you can spare a cycle, for example, when it's time to
> >> clear the accumulator.  This is done by doing separate
> >> multiply-accumulates on the MSB and LSB DSP48s, and then at the end of
> >> the accumulation period, on the spare cycle, summing the two together by
> >> changing the opcode mux.
> >> -Kevin
>
> > Hi, thanks for that.
> > It got crowded in the chip so I kept banging my head against the user
> > guide schematics
> > and came up with the following. To compute A18*B35 + C35 I chain two
> > DSP48 to form
> > a 18x35 multiplier. Then I set
> > C48 <= C(29 downto 0) << 17;
> > and use it as the Z input to the lower DSPs adder.
> > The remaining 6 bits need to be added in fabric. With a simple
> > retiming step I can even use the
> > PREG of the upper DSP slice.
>
> > I understand that there are not enough routing ressources to have to
> > independant C inputs, but as
> > AxB+C is a common function, maybe support for this could be added to
> > the next generation of the DSP slice?
> > All that is needed is an additional mux to split the C input between
> > the two slices.
> > (actually not even that, all is needed are seperate controls for parts
> > of the existing muxes, so the critical
> > path does not get slower.)
>
> > Kolja Sulimma
>
> Kolja,
> I'm not sure exactly what you are describing.  You could take the 30
> bits from the upper (msb) slice's P output and leftshift 17 bits and
> route them to the C input so they can be summed with AxB from the lower
> slice, but then you still can't accumulate.  When you multiply, you have
> to use both the X and Y muxes for the multiplier's partial sums, so then
> you are left with the Z mux, which you can use to add in either C, PCIN,
> or P.  So you can't multiply, accumulate, and add in a third thing at
> the same time.
>
> I'm not sure what you mean by your suggestion about the mux to split the
> C between the two slices.  The C input already goes to both slices.  (By
> the way, the DSP48E in the V5 has independent C inputs for each slice.
> And it does a 25x18 multiply.)  -Kevin


Article: 128660
Subject: Re: Why use small resistor for Vcco voltage regulator
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Sat, 02 Feb 2008 00:55:21 +0100
Links: << >>  << T >>  << A >>
Eric Crabill schrieb:

> The resistor selection is intentional.  In this application, it is desirable 
> to shunt 50 mA directly to ground.  You can do that by adding a third 
> resistor, or by sizing the voltage divider to accomplish the same effect. 
> This "wasted" current prevents the regulator output current from dropping to 
> zero when there is a lot of overshoot.  If you are interested in reading 
> more about it, the application note XAPP457 does contain a discussion on 
> this topic.


"Careful inspection of the original design reveals that the impedance of 
the feedback network is atypically low. Even with zero load, 
approximately 50 mA is lost through the feedback network.
At first, this loss seems undesirable, but it serves an important 
purpose. The I/O protection diodes in Spartan-3 Generation FPGAs form a 
charge pump that can inject excess bus switching energy into the VCCO 
and GND rails. This effect is pronounced when the device is not
participating in a bus transaction, but switching activity from other 
devices generates overshoot/undershoot on the bus signals.
This effect poses a problem for a regulated VCCO rail. Most regulators 
do not tolerate reverse current and might lose voltage regulation under 
such circumstances. One way to solve this problem, at the expense of 
slightly higher power consumption, is to shunt current to the GND
rail as shown in Figure 2."

http://www.xilinx.com/support/documentation/application_notes/xapp457.pdf

For quick access. Sounds logic.

Regards
Falk


Article: 128661
Subject: Re: Why use small resistor for Vcco voltage regulator
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 02 Feb 2008 16:34:57 +1300
Links: << >>  << T >>  << A >>
Eric Crabill wrote:
> Hello,
> 
> The resistor selection is intentional.  In this application, it is desirable 
> to shunt 50 mA directly to ground.  You can do that by adding a third 
> resistor, or by sizing the voltage divider to accomplish the same effect. 
> This "wasted" current prevents the regulator output current from dropping to 
> zero when there is a lot of overshoot.  If you are interested in reading 
> more about it, the application note XAPP457 does contain a discussion on 
> this topic.
> 
> Also, if you can somehow guarantee other components powered by VCCO will 
> always be drawing some minimum current, you can subtract that from the 50 mA 
> and size the voltage divider to be less leaky...
> 
> Eric

Hi Eric,

Yes, Bas pasted that.
My point was that saving one resistor in a App note is perhaps the
wrong emphasis, and you would be better 'protecting the novices from 
themselves' ?.

If that 50mA really is important, the biggest risk
seems to be someone cutting out the ADJ block, and using a Fixed 3,3V reg
[thus saving two more pesky resistors ;) ] - but not realising they
lost the 50mA load at the same time.

-jg


Article: 128662
Subject: spartan3a support DVI ?
From: huangjie <huangjielg@gmail.com>
Date: Fri, 1 Feb 2008 19:55:24 -0800 (PST)
Links: << >>  << T >>  << A >>
 spartan3a support T.M.D.S. signal standard ,but since DVI signals are
1000M or higher ,how can receive data from DVI ?

Article: 128663
Subject: Loading from Compact Flash on ML310...
From: Xesium <amirhossein.gholamipour@gmail.com>
Date: Sat, 2 Feb 2008 02:48:10 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi everybody,
I have written a very simple code for microblaze on Virtex II-Pro
(XC2VP30 on ML310 board) which basically writes something to STD-OUT
(through uart). When I load the design to the FPGA through parallel
cable IV everything works perfectly which gives me the idea that
basically there is nothing wrong with the design in general and the
code. I've been trying to load the design through compact flash for a
few weeks now but I haven't still been able. I'm using EDK 8.2.02 and
ISE 8.2.03. If I generate the .ace file using EDK when I switch on the
board the sysAce Error red LED is turned on meaning that the design is
not loaded appropriately. However when I generate .ace file using
iMPACT from ISE then it sounds like the design is loaded because the
green SysAce Status LED is turned on but it writes nothing to the
hyperterminal through which I'm getting connected to UART on the
board.

Do you have any clue what the problem is?

I appreciate any help beforehand,

Article: 128664
Subject: Re: Why use small resistor for Vcco voltage regulator
From: jasonL <junsong.liao@gmail.com>
Date: Sat, 2 Feb 2008 06:53:52 -0800 (PST)
Links: << >>  << T >>  << A >>
Thank you all, I get the point to have small resistors.
If a little higher cost is allowed, are there any other solutions
consuming less power to better handle overshooting?

Article: 128665
Subject: Re: Design security for pre-Virtex2 parts ?
From: Kris Vorwerk <kris.vorwerk@gmail.com>
Date: Sat, 2 Feb 2008 10:36:30 -0800 (PST)
Links: << >>  << T >>  << A >>
> U can't get security within chips that are provided for the mass
> market.
> everyone who has at least $10000 can backengineer these. It's better
> to work on own solutions.


I disagree; I doubt that you could reverse-engineer Actel's flash or
antifuse parts on a $10k budget.  c.f.,

http://www.actel.com/products/solutions/security/default.aspx

(Design security was one of the primary reasons that ARM chose Actel
for the free release of their ARM7 and Cortex M1 processors.)

regards,
Kris

Article: 128666
Subject: Re: spartan3a support DVI ?
From: austin <austin@xilinx.com>
Date: Sat, 02 Feb 2008 11:10:53 -0800
Links: << >>  << T >>  << A >>
http://www.xilinx.com/support/documentation/boards_and_kits/ug456.pdf

Have you read the user's guide?

Or,

http://www.xilinx.com/bvdocs/ipcenter/user_guide_user_manual/s3a-dsp-3400a-userguide.pdf


Some applications use DVI processing chips.

Austin

Article: 128667
Subject: Internal signal names in ModelSim
From: "Xin Xiao" <x@x.com>
Date: Sat, 2 Feb 2008 21:19:28 +0100
Links: << >>  << T >>  << A >>

I have synthesized and implemented my design, and I was going to simulate 
post-route using ModelSim. The problem is that all internal signals have 
been renamed, and I can't match each signal with the signal name from my 
vhdl code. How can I show the "behavioral" signal names during post-route 
simulation? Or where is the correspondence between vhdl signal names and 
post-route signal names?

Thanks! 


Article: 128668
Subject: Re: Why use small resistor for Vcco voltage regulator
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 03 Feb 2008 09:31:29 +1300
Links: << >>  << T >>  << A >>
jasonL wrote:
> Thank you all, I get the point to have small resistors.
> If a little higher cost is allowed, are there any other solutions
> consuming less power to better handle overshooting?

Sure
- find a regulator that is able to also sink current.
The DDR termination regulators are designed to do just that.

You could also measure your own overshoot energy in each
design, and target that.

-jg


Article: 128669
Subject: Re: Internal signal names in ModelSim
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 02 Feb 2008 20:42:18 GMT
Links: << >>  << T >>  << A >>

"Xin Xiao" <x@x.com> wrote in message 
news:fo2j8i$dv$1@nsnmrro2-gest.nuria.telefonica-data.net...
>
> I have synthesized and implemented my design, and I was going to simulate 
> post-route using ModelSim. The problem is that all internal signals have 
> been renamed, and I can't match each signal with the signal name from my 
> vhdl code. How can I show the "behavioral" signal names during post-route 
> simulation?

You'll have to hunt for them in the VHDL file that the synthesis tool 
produced for the post-route design.  It's painful, no shortcuts that I know 
of.

Kevin Jennings 



Article: 128670
Subject: Re: Internal signal names in ModelSim
From: John Retta <jretta@rtc-inc.com>
Date: Sat, 02 Feb 2008 15:15:04 -0700
Links: << >>  << T >>  << A >>
[1] One selective technique might be to bring
a subset of signals to test points that will
be external to FPGA.

[2] Real question though is why do post route
simulation .... if it were easy, or if this were
an ASIC, but if your design is synchronous, and
well constrained, you can bypass post route
simulation.

I have completed maybe 40 Xilinx designs in the
last 6 years, and have not run a single back
annotated simulation.

Good luck.

-- 

Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

Colorado Based Xilinx Consultant

phone : 303.926.0068
email : jretta@rtc-inc.com
web   :  www.rtc-inc.com

Article: 128671
Subject: Re: Internal signal names in ModelSim
From: mk <kal*@dspia.*comdelete>
Date: Sat, 02 Feb 2008 22:23:12 GMT
Links: << >>  << T >>  << A >>
On Sat, 2 Feb 2008 21:19:28 +0100, "Xin Xiao" <x@x.com> wrote:

>
>I have synthesized and implemented my design, and I was going to simulate 
>post-route using ModelSim. The problem is that all internal signals have 
>been renamed, and I can't match each signal with the signal name from my 
>vhdl code. How can I show the "behavioral" signal names during post-route 
>simulation? Or where is the correspondence between vhdl signal names and 
>post-route signal names?
>
>Thanks! 

In general there is none but there are some cases which might be
helpful. Usually module ports are preserved so you can put the names
you're interested as module outputs and still have them available.
They don't even have to be at the top level (usually). The other case
is registers are usually quite predictively changed ie a register
foo[7:0] almost always gets named foo_reg_7, foo_reg_6 etc. You can
use this to access your signals.
One question is that why you need to see your internal signals in gate
level. Even if you feel the need to do gate-level back-annotated sims,
surely you don't need to debug them there unless of course you're
trying to catch an apparent incorrectly generated hardware problem but
that's very rare and the problem is almost always somewhere else.
Debug your circuits in RTL fully and make sure you meet timing in P&R
then you don't have to debug gate-level.

Article: 128672
Subject: Re: Active-HDL 7.3 vs Modelsim 6.3d-PE (for Verilog/Systemverilog)
From: "talkb" <noone@talkb.com>
Date: Sun, 03 Feb 2008 00:00:29 GMT
Links: << >>  << T >>  << A >>

"John McCaskill" <jhmccaskill@gmail.com> wrote in message 
news:b51a42ee-da15-40dd-a53b-a32c04561f6c@u10g2000prn.googlegroups.com...
> The OP asked what EDK supports, compxlib is part of ISE, not EDK.  I
> am currently using EDK/ISE 8.1 8.2 and 9.1, and I see that ISE does
> support vcs, but EDK does not. I also use ModelSim but not Cadence.
>
> When I say that EDK supports ModelSim and Cadence, I mean two things.
>
> 1. For those simulators the SimGen tool will generate setup scripts
> for you from your EDK project that let you launch the simulator,
> compile the project, setup the display windows, and run the
> simulation.  I think that this is a very nice feature, but if you
> prefer another simulator, you can of course do this yourself.
>
> 2. Xilinx presumably does quality assurance testing against the
> simulators that they say are supported, and will provide help if you
> have problems. To me this is the critical point.
>
> At least for ModelSim, Xilinx is very specific about which versions
> they support. In the case of EDK 8.2, they specify one specific
> release of ModelSim as the only supported version.  We have tried
> running with other versions with mixed results.  When we used the
> supported version, our test benches passed and matched what we saw in
> hardware.  When we used other versions, some times we got the same
> results, some times we did not.

!!! That kind of version-dependency annoys/disturbs me.  Why
can't Xilinx just make/test their libraries with all versions /forward/ of
a specific revision (like 6.1e or later)?

Looks like I'll hvae to run some EDK-simulation tests with Active-HDL,
and see what problems (if any) I encounter.

By the way, thank you for your cautionary perspective.  All too often,
I take forgranted that "if version x is verified working, and y > x, then
version y ought to work too." Bzzt -- false! 



Article: 128673
Subject: Re: spartan3a support DVI ?
From: huangjie <huangjielg@gmail.com>
Date: Sat, 2 Feb 2008 19:05:48 -0800 (PST)
Links: << >>  << T >>  << A >>
Thanks !
 I  have read ug456 and  s3a-dsp-userguide , this board use TI's
TFP403,
But I want directly input DVI signal without TFP403 since SPARTAN3A
support TMDS signal standard.
I'm confused by XILINX since spartan3a support TMDS,but how can I use
it  since spartan3a does not support giga-bit serdes.
Have Xilinx developed soft serdes can support 1G ?

On 2=D4=C23=C8=D5, =C9=CF=CE=E73=CA=B110=B7=D6, austin <aus...@xilinx.com> w=
rote:
> http://www.xilinx.com/support/documentation/boards_and_kits/ug456.pdf
>
> Have you read the user's guide?
>
> Or,
>
> http://www.xilinx.com/bvdocs/ipcenter/user_guide_user_manual/s3a-dsp-...
>
> Some applications use DVI processing chips.
>
> Austin


Article: 128674
Subject: Re: spartan3a support DVI ?
From: Antti <Antti.Lukats@googlemail.com>
Date: Sun, 3 Feb 2008 00:15:06 -0800 (PST)
Links: << >>  << T >>  << A >>
On 3 Feb., 04:05, huangjie <huangji...@gmail.com> wrote:
> Thanks !
>  I  have read ug456 and  s3a-dsp-userguide , this board use TI's
> TFP403,
> But I want directly input DVI signal without TFP403 since SPARTAN3A
> support TMDS signal standard.
> I'm confused by XILINX since spartan3a support TMDS,but how can I use
> it  since spartan3a does not support giga-bit serdes.
> Have Xilinx developed soft serdes can support 1G ?
>
> On 2=D4=C23=C8=D5, =C9=CF=CE=E73=CA=B110=B7=D6, austin <aus...@xilinx.com>=
 wrote:
>
> >http://www.xilinx.com/support/documentation/boards_and_kits/ug456.pdf
>
> > Have you read the user's guide?
>
> > Or,
>
> >http://www.xilinx.com/bvdocs/ipcenter/user_guide_user_manual/s3a-dsp-...
>
> > Some applications use DVI processing chips.
>
> > Austin

Xilinx only says TMDS not DVI :)

so while limited DVI output may be possible full speed DVI input is
not.
and ASFAIK there is no DVI reference design available for S3A :(

Antti

http://www.truedream.org/smile/MyFirstFlashFpgaCert.pdf



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