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
2019JanFebMar2019

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 126150

Article: 126150
Subject: Re: synopsys translate_off
From: Pasacco <pasacco@gmail.com>
Date: Thu, 15 Nov 2007 10:27:24 -0800 (PST)
Links: << >>  << T >>  << A >>
Dear
I could not resove this problem.

UNISIM and XILINXCORELIB are properly mapped to Modelsim.

The thing is that

The VHDL files "in Pcore directory" contain following:
(BRAMs are instantiated in the VHDL.)

--------------------------------------
-- pragma translate_off
library	VIRTEX2;
use VIRTEX2.all;
-- pragma translate_on
--------------------------------------

When I try "do system.do", error occurred "Virtex2 library not found".

When I comment the "Virtex2 library declaration" and I try "do
system.do",
no error and no warning occurred.

--------------------------------------
-- pragma translate_off
--library	VIRTEX2;
--use VIRTEX2.all;
-- pragma translate_on
--------------------------------------

Problem is that

When I try "vcom -work work testbench.vhd", then following warning
occurs.

-----------------------
Warning: Component instance "ramx32 : ramb16_s36_s36" is not bound.
-----------------------

This means that BRAM block is disappeared.

As a result, I do not see any signal toggling in the waveform in
Modelsim.

My question is that

What does the following mean?
How can we find the library "VIRTEX2" and map?
--------------------------------------
-- pragma translate_off
library	VIRTEX2;
use VIRTEX2.all;
-- pragma translate_on
--------------------------------------

Thank you for reply in advance.

Article: 126151
Subject: Re: EDK 9.1 Issues
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Thu, 15 Nov 2007 18:41:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
Thanks for trying to help, but it didn't work.  I updated a simple piece 
of hardware to use a different bit to drive an LED (1/2 as fast blinking), 
saved, hit the refresh repositories button, after implementation... same 
old results.


---Matthew Hicks


> Matthew Hicks wrote:
> 
>> When working with custom peripherals in EDK, is there a better way to
>> make sure changes to the hardware design take effect than trying to
>> re-import the peripheral?  I spent several hours last night debugging
>> a design that was failing because EDK wasn't loading the updated
>> hardware design (just logic, no change in external ports).  I made
>> sure it did a fresh synth+impl run every time, but somehow the
>> functionality never changed even though the hw design did.  Even
>> after removing the instance and re-importing and re-connecting it.  I
>> finally got it to work by creating a completely new hw design (in
>> name only) with the same logical functionality and using it in place
>> of the previous block.
>> 
> I think Project->Rescan User Repositories will solve your problem.
> 



Article: 126152
Subject: Re: Xilinx Virtex-II Newbie
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 16 Nov 2007 07:41:53 +1300
Links: << >>  << T >>  << A >>
EEngineer wrote:
> On Nov 15, 9:41 am, Andrew Ganger <Andre...@yahoo.co.uk> wrote:
> 
>>>Two write ports sounds dangerous :) -  but classic RISC devices
>>>might need 3 read ports, and one write port
>>
>>>Rd = Ra OPERAND Rb OPERAND Rc
>>
>>>one fast/simple idea I had for emulating this on dualport memory is to
>>>use two blocks and simply parallel  the one write port
>>>- so the two have identical info, and would actually give 4 read ports
>>
>>>Yes, it's a little redundant, but easy to implement, and the RegFiles
>>>are small anyway.
>>
>>Yeah, it might be dangerous, but in my case I would need two write ports ;).
>>
>>So yeah, this sounds like a good idea. So I would have two RAM blocks
>>each with two read, and two write ports. In this case I write the result
>>back simultanlously in both register files. Looks like a good idea for
>>a first evaluation!
>>
>>Thanks!
> 
> 
> Probelem with this is what if more than two registers that need to be
> written are located at the same RAM block! I am using 8 parallel
> blocks in my design as I am writting 8 memory locations at a time but
> I am sure that all 8 memory locations belong to different RAM block.

Err, no?. What you do is keep the 4 read poert separate, and parallel
each side's write ports - so you always write to TWO locations at once.
You have consumed block ram, for the  sake of simplicity and speed.
You always write-before-using, both blocks have identical contents.

The only danger case is if the SW writes to (eg) R13 and R13, which 
could be trapped in HW, and/or in the assembler.

-jg



Article: 126153
Subject: Re: synopsys translate_off
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: Thu, 15 Nov 2007 19:57:26 +0100 (CET)
Links: << >>  << T >>  << A >>
In
news:e5335b73-f4dc-476a-8945-c2b3ff99a53e@b15g2000hsa.googlegroups.com
timestamped Thu, 15 Nov 2007 10:27:24 -0800 (PST), Pasacco
<pasacco@gmail.com> posted:
|----------------------------------------------------------------------|
|"[..]                                                                 |
|                                                                      |
|My question is that                                                   |
|                                                                      |
|What does the following mean?                                         |
|How can we find the library "VIRTEX2" and map?                        |
|--------------------------------------                                |
|-- pragma translate_off                                               |
|library VIRTEX2;                                                      |
|use VIRTEX2.all;                                                      |
|-- pragma translate_on                                                |
|--------------------------------------                                |
|                                                                      |
|Thank you for reply in advance."                                      |
|----------------------------------------------------------------------|

-- pragma translate_off is to inform Synopsys to not to try to
synthesize the following code before -- pragma translate_on. The
intention is to allow code which can be e.g. simulated but which is
not to be synthesized, but you are experiencing a problem in getting
the simulation to run. Is it extremely important to you to have a
precise model of the BRAM? Would it be acceptable to substitute the
synthesized Virtex2's BRAMs with a functional generic RAM in the simulation?

Article: 126154
Subject: Re: synopsys translate_off
From: Pasacco <pasacco@gmail.com>
Date: Thu, 15 Nov 2007 11:26:32 -0800 (PST)
Links: << >>  << T >>  << A >>
> -- pragma translate_off is to inform Synopsys to not to try to
> synthesize the following code before -- pragma translate_on. The
> intention is to allow code which can be e.g. simulated but which is
> not to be synthesized, but you are experiencing a problem in getting
> the simulation to run. Is it extremely important to you to have a
> precise model of the BRAM? Would it be acceptable to substitute the
> synthesized Virtex2's BRAMs with a functional generic RAM in the simulation?

When I simulate, I do not see any signal toggling in the waveform,
because BRAMs are unconnected.

Actually the "pcores" are provided by a vendor.
I could modify the VHDL code, but it is too time consuming.
According to your reply, there might exist "specific Virtex2" library
for the BRAMs.
Are there any way to find the Virtex2 library, to simulate with
Modelsim?
Thank you for reply.

Article: 126155
Subject: Re: EDK 9.1 Issues
From: Daniel Koethe <dkoethe@nospam-web.de>
Date: Thu, 15 Nov 2007 21:02:51 +0100
Links: << >>  << T >>  << A >>
Matthew Hicks schrieb:
> When working with custom peripherals in EDK, is there a better way to
> make sure changes to the hardware design take effect than trying to
> re-import the peripheral?  I spent several hours last night debugging a
> design that was failing because EDK wasn't loading the updated hardware
> design (just logic, no change in external ports).  I made sure it did a
> fresh synth+impl run every time, but somehow the functionality never
> changed even though the hw design did.  Even after removing the instance
> and re-importing and re-connecting it.  I finally got it to work by
> creating a completely new hw design (in name only) with the same logical
> functionality and using it in place of the previous block.
> 
> 
> ---Matthew Hicks
> 
> 
hello Matthew,
you can for development of IP-Cores set in the .mpd file the OPTION
CORE_STATE to "DEVELOPMENT".

OPTION CORE_STATE = DEVELOPMENT

See also in the EDK doc directory the Manual Platform Specification
Format Reference Manual (psf_rm.pdf) Page 42 (EDK 8.2 Version).


The core will every time synthesized if you change any bit.

Best regards,
Daniel




Article: 126156
Subject: Re: synopsys translate_off
From: Pasacco <pasacco@gmail.com>
Date: Thu, 15 Nov 2007 12:05:09 -0800 (PST)
Links: << >>  << T >>  << A >>
Thank you for reply.

When I simulate, I do not see any signal toggling in the waveform,
because BRAMs are unconnected.

Actually the "pcores" are provided by a vendor.
I could modify the VHDL code, but it is too time consuming.
According to your reply, there might exist "specific Virtex2" library
for the BRAMs.

Name of the BRAM primitive is "ram_dp".

Are there any way to find the Virtex2 library, to simulate with
Modelsim?

Maybe my problem is not a "library problem".

Article: 126157
Subject: Re: EDK 9.1 Issues
From: Duane Clark <junkmail@junkmail.com>
Date: Thu, 15 Nov 2007 12:12:04 -0800
Links: << >>  << T >>  << A >>
Matthew Hicks wrote:
> When working with custom peripherals in EDK, is there a better way to make 
> sure changes to the hardware design take effect than trying to re-import 
> the peripheral?  I spent several hours last night debugging a design that 
> was failing because EDK wasn't loading the updated hardware design (just 
> logic, no change in external ports).  I made sure it did a fresh synth+impl 
> run every time, but somehow the functionality never changed even though the 
> hw design did.  Even after removing the instance and re-importing and re-connecting 
> it.  I finally got it to work by creating a completely new hw design (in 
> name only) with the same logical functionality and using it in place of the 
> previous block.

Remove the corresponding generated .ngc files, including the ones in the 
cache directory:
	rm implementation/my_wrapper.ngc
	rm implementation/cache/my_wrapper.ngc
(rm is a Linux command, in case you are on Windows)
When you rerun the synthesis, it will rebuild the files from the new code.

Article: 126158
Subject: Re: synopsys translate_off
From: Duane Clark <junkmail@junkmail.com>
Date: Thu, 15 Nov 2007 20:30:09 GMT
Links: << >>  << T >>  << A >>
Pasacco wrote:
> Thank you for reply.
> 
> When I simulate, I do not see any signal toggling in the waveform,
> because BRAMs are unconnected.
> 
> Actually the "pcores" are provided by a vendor.
> I could modify the VHDL code, but it is too time consuming.
> According to your reply, there might exist "specific Virtex2" library
> for the BRAMs.
> 
> Name of the BRAM primitive is "ram_dp".

I am a little puzzled by that statement. Earlier you said:

> When I try "vcom -work work testbench.vhd", then following warning
> occurs.
> 
> -----------------------
> Warning: Component instance "ramx32 : ramb16_s36_s36" is not bound.
> -----------------------

In that case, the BRAM primitive name is ramb16_s36_s36. That primitive 
is a standard one available in the Xilinx unisim library.

> 
> Are there any way to find the Virtex2 library, to simulate with
> Modelsim?
> 
> Maybe my problem is not a "library problem".

Yes, it is a library problem. Your vendor appears to be doing things in 
a weird way, and a bit more info is needed to figure out what they are 
doing.

Show all the library declarations in the file (not just the virtex2 ones).

If there is a component declaration for the bram at the beginning of the 
architecture (that is, before the 'begin' statement), show that.

Show the component instantiation of the bram within the body of the 
architecture. If there are multiple instantiations, just show one.

Article: 126159
Subject: Re: Xilinx Chipscope Pro in EDK system - ILA:how specify separate
From: roger <roger.jons@gmail.com>
Date: Thu, 15 Nov 2007 12:48:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 15, 4:08 am, Andrew FPGA <andrew.newsgr...@gmail.com> wrote:
> Hi,
> This is an embarrassing question to be asking - how does one attach
> signals from the edk design to the chipscope ILA? When I sit down at
> my desk to debug with a benchtop logic analyser, the first thing I do
> is attach the probes to the pcb - I kinda expected it would be simple
> and straightforward with chipscope pro also?
>
> I'm using EDK 9.1i, sp3. I used the debug->debug config menu and
> selected an ILA. Its easy to select signals and add them to Trig0. But
> if I want the trigger and data capture signals to be different, where
> and how do I attach signals in my design to the data capture port on
> the ILA?
>
> (I have limited resources remaining on my FPGA and I only need a few
> simple signals connected to the trigger input, but I want a wider
> selection of signals captured in the trace buffer)
>
> I tried manually editing the ILA component in the .mhs file, by adding
> the entry below:
>
> PORT DATA =
> EthInterfaceTimestamp_0_rx_dv_falling_edge_r_to_chipscope_ila_0 &
> EthInterfaceTimestamp_0_rx_dv_rising_edge_r_to_chipscope_ila_0 &
> EthInterfaceTimestamp_0_tx_en_falling_edge_r_to_chipscope_ila_0 &
> EthInterfaceTimestamp_0_tx_en_rising_edge_r_to_chipscope_ila_0 &
> EthInterfaceTimestamp_0_timestamp_to_chipscope_ila_0
>
> Which caused edk to crash...Is editing the .mhs file ok?
>
> Regards
> Andrew

Hi Andrew,

It is very straightforward, you have one data port and one trig port
on the chipscope IP in EDK. Then you have to configure the IP by right-
clicking the IP and choose configure IP. You have to set the data and
trigger port widths. You should only edit the mhs file if your'e
certain about the syntax.

Regards,
Roger

Article: 126160
Subject: Re: EDK 9.1 Issues
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Thu, 15 Nov 2007 20:52:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
Following your advice, I edited the .mpd file for the core to include the 
"CORE_STATE" option.  After going back into EDK and refreshing repositories, 
the .mpd change was reflected in EDK.  After going through the complete implementation 
process, everything works as it should.  Thanks for this tip (I wish it would 
be default behavior, or more evident that this option exists during import), 
you saved me many more hours of uneeded hassel.  Also, thanks for the reference 
where I can read-up more on other options.


---Matthew Hicks


> Matthew Hicks schrieb:
> 
>> When working with custom peripherals in EDK, is there a better way to
>> make sure changes to the hardware design take effect than trying to
>> re-import the peripheral?  I spent several hours last night debugging
>> a design that was failing because EDK wasn't loading the updated
>> hardware design (just logic, no change in external ports).  I made
>> sure it did a fresh synth+impl run every time, but somehow the
>> functionality never changed even though the hw design did.  Even
>> after removing the instance and re-importing and re-connecting it.  I
>> finally got it to work by creating a completely new hw design (in
>> name only) with the same logical functionality and using it in place
>> of the previous block.
>> 
>> ---Matthew Hicks
>> 
> hello Matthew,
> you can for development of IP-Cores set in the .mpd file the OPTION
> CORE_STATE to "DEVELOPMENT".
> OPTION CORE_STATE = DEVELOPMENT
> 
> See also in the EDK doc directory the Manual Platform Specification
> Format Reference Manual (psf_rm.pdf) Page 42 (EDK 8.2 Version).
> 
> The core will every time synthesized if you change any bit.
> 
> Best regards,
> Daniel



Article: 126161
Subject: Re: EDK 9.1 Issues
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Thu, 15 Nov 2007 21:05:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
Thanks, this also works.


---Matthew Hicks


> Matthew Hicks wrote:
> 
>> When working with custom peripherals in EDK, is there a better way to
>> make sure changes to the hardware design take effect than trying to
>> re-import the peripheral?  I spent several hours last night debugging
>> a design that was failing because EDK wasn't loading the updated
>> hardware design (just logic, no change in external ports).  I made
>> sure it did a fresh synth+impl run every time, but somehow the
>> functionality never changed even though the hw design did.  Even
>> after removing the instance and re-importing and re-connecting it.  I
>> finally got it to work by creating a completely new hw design (in
>> name only) with the same logical functionality and using it in place
>> of the previous block.
>> 
> Remove the corresponding generated .ngc files, including the ones in
> the
> cache directory:
> rm implementation/my_wrapper.ngc
> rm implementation/cache/my_wrapper.ngc
> (rm is a Linux command, in case you are on Windows)
> When you rerun the synthesis, it will rebuild the files from the new
> code.
> 



Article: 126162
Subject: Re: FPGA for hobby use
From: Andy <jonesandy@comcast.net>
Date: Thu, 15 Nov 2007 14:21:32 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 15, 2:41 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> - The essential drawback is the missing back annotation of the simulation
>   results into the schematic. This is like debugging software with print
>   statements instead of a source code debugger. A few years ago I tested
>   an older version (I think it was ISI 2.1) and there at least you could
>   attach probes in the schematic to display the states of signals.
>   This also was only a makeshift, but better than nothing.

Now that's funny!  You don't like HDL, but a source level (text)
debugger is a better idea?

Just how do you do a simulation without some sort of textual
stimulation (or with an hdl, at least  you can have behavioral
stimulation)? Please don't tell me  you click on a wire and start
typing ones and zeroes?

I think the bottom line is that graphics show structure better, text
shows behavior better. I use RTL viewers (synplicity and quartus are
really good) to extract the structural graphics from my HDL source if/
when I need it (presentations, reviews, etc.) It is a lot easier to do
that than to specify (or debug) behavior from graphics.

I'm old enough have done a lot of ABEL/CUPL for PALs, and schematic
capture for xc2000/xc3000 designs, and I hated VHDL for a long time.
My old boss hung up a quote of mine about trying to design SW by
drawing pictures, while HW design was hell-bent-for-leather, headed
the other way. Previous poster notwithstanding, I used GED (precursor
to Concept) to build wonderful, intelligently parameterizable
functional blocks that could be interconnected in an easily
understood, structual way. Unless I needed to design a state
machine... That's when I started to design behaviorally, instead of
structurally. Now, design structure is mostly about managing
behavioral complexity, and a only little about managing physical
complexity. Once you make that thought shift, it's gravy from there
on.

So where is the future of "schematic capture"? Just like in board
level design, when you are designing structurally with pre-
manufactured blocks, and just hooking them up with wires, that's where
graphical design entry makes sense. We're probably headed back there
with FPGA's, what with increased use of IP, where the bulk of our
"design" is hooking up pre-designed blocks of circuitry. So we dive
into a custom block every now and then to use HDL to design a custom
behavioral translator to make block A talk to block B...

BTW, I've used Concept and Capture (Orcad) for board design, and trust
me, Concept is WAY ahead of Capture. They keep adding features from
Concept into Capture though, so one of these days...

Alright, I've ambled on enough.

Andy

Article: 126163
Subject: Re: Block-ram FIFO in Xilinx
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 15 Nov 2007 14:22:49 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 15, 3:14 am, "zlotawy" <paraliczb@NO_SPAM_orange.pl> wrote:
> Uzytkownik "Peter Alfke" <pe...@xilinx.com> napisal w wiadomoscinews:1195079702.949034.33320@e9g2000prf.googlegroups.com...
>
> >A large asynchronous FIFO will always most efficiently be implemented
> > in a dual-ported BlockRAM, and have a width of 1, 2, 4, 9, 18, or 36
> > bits. If you need a different width, just pad it to the higher value.
> > Also Din and Dout have the same width.
> > Anything different will get very complicated...
> > The main problem in the design of asynchronous (2-clock) FIFOs is the
> > reliable generation of the Full and Empty flags at high clock rates.
>
> hmmm... which clock sets flags?
>
> And what if two clocks are the same? Then should I change type of fifo (one
> clock)?
>
> zlotawy

If both clocks are the same, the design becomes a trivial synchronous
state machine. Only fast asynchronous FIFO controllers are tricky and
somewhat controversial, due to the metastable risk and its avoidance.
Peter Alfke

Article: 126164
Subject: Re: Xilinx Chipscope Pro in EDK system - ILA:how specify separate
From: Andrew FPGA <andrew.newsgroup@gmail.com>
Date: Thu, 15 Nov 2007 14:58:42 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Roger,
Thanks for the info, but following your suggestion does not appear to
be any different than going to the menu Debug->debug configuration and
selecting ila0.
Sure you can set the trigger port width and data width. You can also
add signals to the Trigger input. But how do I add signals to the DATA
ila input?
I can use the system assembly view with ports filter is see the ILA
ports. I can see the data port, but the connection drop down list only
allows me to connect one signal at a time. Of course I want to connect
several different signals to the Ila Data port but can't see how?

> It is very straightforward, you have one data port and one trig port
> on the chipscope IP in EDK.
Yes it describes this in the documentation, but it is quite unclear as
to how one connects signals in the design to the Data port.

> Then you have to configure the IP by right-
> clicking the IP and choose configure IP. You have to set the data and
> trigger port widths. You should only edit the mhs file if your'e
> certain about the syntax.
Yeah, and I don't know the syntax for the Data port, nor have I been
able to find it. :(



Article: 126165
Subject: Re: V4FX: Cannot access EMAC1 of Dual MAC system
From: Ben Jackson <ben@ben.com>
Date: Thu, 15 Nov 2007 17:02:33 -0600
Links: << >>  << T >>  << A >>
On 2007-11-15, JimboD2@gmail.com <JimboD2@gmail.com> wrote:
>
> Using chipscope, i've observed that the host bus to the hard MAC is
> functioning during read/writes for emac0, but not when addressing
> emac1. It seems that the plb_temac for emac1 does not initiate a
> transfer on the host bus.

You probably forgot to set C_TEMAC_INST in the second PLB temac (in
addition to C_TEMAC_BOTH_USED).

I hear there is tcl code to catch this in Xilinx's code, but it's commented
out...

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 126166
Subject: Lattice Semi
From: "Colin Hankins" <Colin.Hankins@touit.com>
Date: Thu, 15 Nov 2007 15:59:22 -0800
Links: << >>  << T >>  << A >>
Has anyone worked with the Lattice Semiconductor ECP2M series of FPGA? Were 
the parts easy to get? Also, how is the ispLever design software from 
Lattice?

I've worked exclusively with Xilinx FPGAs and am looking for some feedback 
about what else is out there. My particular interest developed in the 
Lattice ECP2M because I need a FPGA/SERDES combo and the price for the ECP2M 
seems unbelievable compared to their competitor's equivalent FPGAs. So, I'm 
thinking something must be wrong?

Thanks,
Colin 



Article: 126167
Subject: Re: Lattice Semi
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 15 Nov 2007 16:50:57 -0800
Links: << >>  << T >>  << A >>
"Colin Hankins" <Colin.Hankins@touit.com> wrote in message 
news:A35%i.17632$pr6.16558@newsfe06.phx...
> Has anyone worked with the Lattice Semiconductor ECP2M series of FPGA? 
> Were the parts easy to get? Also, how is the ispLever design software from 
> Lattice?
>
> I've worked exclusively with Xilinx FPGAs and am looking for some feedback 
> about what else is out there. My particular interest developed in the 
> Lattice ECP2M because I need a FPGA/SERDES combo and the price for the 
> ECP2M seems unbelievable compared to their competitor's equivalent FPGAs. 
> So, I'm thinking something must be wrong?
>
> Thanks,
> Colin

I want to work with the parts but have yet to get the design start with 
Lattice because of unrelated issues.  My personal belief is that they 
targeted the right mix of features at the right time to hit big holes in the 
competitions' low-cost portfolios.  Given reasonable cost of dedicated 
high-speed devices out there, I just don't understand why SerDes *should* 
cost as much as is implied by other FPGA vendors.  Another aspect: Lattice 
is probably hungrier than the big guys to get those design wins to establish 
themselves as a strong player.

I hope we both get a chance to work with the ECP2Ms.

- John_H 



Article: 126168
Subject: TI DSP soft core in Xilinx?
From: "cpope" <cepope@nc.rr.com>
Date: Thu, 15 Nov 2007 19:53:42 -0500
Links: << >>  << T >>  << A >>
I have a V4FX based product and I'd like to have a DSP coprocessor to go
with the the powerpc that handles my operating system. Are there TI c54x or
c3x soft cores out there that could be compiled into a xilinx fpga? Could be
anyone's dsp, I suppose, so long as it has a large existing code base and
mature tools.

Also is microblaze an option? Can it do significant DSP?

Thanks,
Clark



Article: 126169
Subject: Re: synopsys translate_off
From: "beeraka@gmail.com" <beeraka@gmail.com>
Date: Thu, 15 Nov 2007 18:35:38 -0800 (PST)
Links: << >>  << T >>  << A >>
You still are not adding the Library stuff when you are calling "vcom"

vcom -L XILINXCORELIB_VER -L UNISIM work.testbench

Hope this helps.

-- parag

On Nov 15, 12:27 pm, Pasacco <pasa...@gmail.com> wrote:
> Dear
> I could not resove this problem.
>
> UNISIM and XILINXCORELIB are properly mapped to Modelsim.
>
> The thing is that
>
> The VHDL files "in Pcore directory" contain following:
> (BRAMs are instantiated in the VHDL.)
>
> --------------------------------------
> -- pragma translate_off
> library VIRTEX2;
> use VIRTEX2.all;
> -- pragma translate_on
> --------------------------------------
>
> When I try "do system.do", error occurred "Virtex2 library not found".
>
> When I comment the "Virtex2 library declaration" and I try "do
> system.do",
> no error and no warning occurred.
>
> --------------------------------------
> -- pragma translate_off
> --library       VIRTEX2;
> --use VIRTEX2.all;
> -- pragma translate_on
> --------------------------------------
>
> Problem is that
>
> When I try "vcom -work work testbench.vhd", then following warning
> occurs.
>
> -----------------------
> Warning: Component instance "ramx32 : ramb16_s36_s36" is not bound.
> -----------------------
>
> This means that BRAM block is disappeared.
>
> As a result, I do not see any signal toggling in the waveform in
> Modelsim.
>
> My question is that
>
> What does the following mean?
> How can we find the library "VIRTEX2" and map?
> --------------------------------------
> -- pragma translate_off
> library VIRTEX2;
> use VIRTEX2.all;
> -- pragma translate_on
> --------------------------------------
>
> Thank you for reply in advance.






Article: 126170
Subject: Re: Lattice Semi
From: lb.edc@telenet.be
Date: Fri, 16 Nov 2007 08:02:02 GMT
Links: << >>  << T >>  << A >>
HI Colin,

A couple of weeks ago, one of the local FAE's told me that only the
biggest device/package (ECP2M100-F1152) is not available in
production. This means that you should be able to get parts quickly.

I have personally worked with ECP2M20-F256 on a video board
(HD/SD-SDI) and I haven't encountered big issues. I got it to work in
some 2 weeks time. And yes you are right, the price of the ECP2M
family vs. competitor's equivalent IS incredible. The price was cut by
two.

Success with your implementation.

Luc

On Thu, 15 Nov 2007 15:59:22 -0800, "Colin Hankins"
<Colin.Hankins@touit.com> wrote:

>Has anyone worked with the Lattice Semiconductor ECP2M series of FPGA? Were 
>the parts easy to get? Also, how is the ispLever design software from 
>Lattice?
>
>I've worked exclusively with Xilinx FPGAs and am looking for some feedback 
>about what else is out there. My particular interest developed in the 
>Lattice ECP2M because I need a FPGA/SERDES combo and the price for the ECP2M 
>seems unbelievable compared to their competitor's equivalent FPGAs. So, I'm 
>thinking something must be wrong?
>
>Thanks,
>Colin 
>

Article: 126171
Subject: Re: newbie to 16v8
From: "BobW" <nimby_NEEDSPAM@roadrunner.com>
Date: Fri, 16 Nov 2007 00:15:44 -0800
Links: << >>  << T >>  << A >>

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
news:lrgoj3d81f2jgs5jtd1rc037b9qmugn89v@4ax.com...
> On Wed, 14 Nov 2007 18:31:15 -0800 (PST), Amit <amit.kohan@gmail.com>
> wrote:
>
>>On Nov 12, 8:57 am, Ray Andraka <r...@andraka.com> wrote:
>>Hi Ray,
>
>>Thank your response. what is your webiste's domain?
>
> I think I'd try www.andraka.com just to see what happened...
>
> - Brian

I firmly believe that there needs to be some sort of universally-accepted 
occupational guidance test put into place. Here is a candidate for the first 
and only question:

1 - Find Ray Andraka's website on your own.

If one fails this test then that person would be forced to look deeply into 
a mirror and would be strongly encouraged to consider a more menial 
occupation.

Bob



Article: 126172
Subject: Re: Structured way of changing eg time constants for real world build / simulation?
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Fri, 16 Nov 2007 09:12:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2007-11-13, Andy <jonesandy@comcast.net> wrote:
> I've been wishing for user defined modes for record type ports (or
> procedure arguments), used in lieu of in, out or inout, that would
> allow you to specify the mode of each individual element. If only we
> could do something like:
>
>   type bus_type is record
>     data : std_logic_vector(31 downto 0);
>     ack : std_logic;
>     ...
>   end record;
>   mode slave of bus_type is (data => inout; ack => out; others => in);
>   mode master of bus_type is (data => inout; ack | clk | rst => in;
> others => out);

If you aren't too attached to VHDL you could look at SystemVerilog
which has exactly this functionality. Keywords to look for are
"interface" and "modport".

/Andreas

Article: 126173
Subject: Re: USR_ACCESS_VIRTEX4 usage
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 16 Nov 2007 01:43:47 -0800 (PST)
Links: << >>  << T >>  << A >>
On 14 Nov., 18:34, Jan Pech <n...@spam.please> wrote:
> Hello all,
>
> I would like to use the USR_ACCESS_VIRTEX4 primitive to access an
> additional bitstream stored in a config  flash. The situation is
> following:
> * I have a master FPGA (Virtex-4FX) and a slave FPGA (Spartan-3A). The
> slave FPGA is located on an additional board and it is NOT daisy-chained
> with the master one.
> * Master FPGA gets configured out of platform flash in master serial
> mode.
> * I need to configure even the slave FPGA. The only non-volatile source
> of its configuration data is the platform flash connected to the master
> FPGA.
>
> I used STARTUP_VIRTEX4 primitive to take control over the CCLK and DONE
> signals. While generating bitstream I used the "-g DONE_cycle:KEEP"
> option. From my measurements of the interface between flash and
> Virtex-4, this part of the design works fine. I fully control the
> signals, DONE does not go high anywhere in the middle, and flash sends
> me additional bitstream data.
>
> To access additional bitstream I instantiated the USR_ACCESS_VIRTEX4
> primitive, but here is the problem. Even though I see the data on the
> DIN input of the Virtex-4, the DATAVALID output of the
> USR_ACCESS_VIRTEX4 primitive never goes high. So that I am unable to
> reach this data inside the Virtex-4 FPGA.
>
> The Virtex-4 Libraries Guide for HDL Design says: The PROM should
> contain a packet of data with the USR_ACCESS register as the target. I
> generated my PROM file using iMPACT simply putting two bitstreams into
> single MCS file what is probably wrong. I think my MCS should contain
> normal master FPGA bitstream followed by the slave FPGA bitsream with
> target set to USR_ACCESS. Is there any way how to set target for the
> second bitsream in MCS to USR_ACCESS so that I could access it from my
> master FPGA?
>
> If I am trying to do something impossible, is there another approach how
> read slave configuration data from platform flash using master FPGA? I
> cannot do it simply controlling flash pins, as they are not connected to
> IO pins of the FPGA but to dedicated configuration pins only.
>
> Thanks for advices,
> Jan

no no no :)

what you want is doable ok, but not with the tools provided by xilinx

.

you need
1) your own bit file merge tool that converts and inserts specially
formatted bitstream into master bitstream
2) your own USR_ACCESS_TO_SERCONFIG gateway IP-core that you compile
into the master FPGA

please look at ultracontroller reference designs, xilinx uses this
(very similar method) to load the PPC memories
they add the info into master bitstream and use usr_access connected
JTAG master ip core

Antti

Article: 126174
Subject: jitter-sensitive multi-output clk distribution for multi-gigabit-transceivers
From: "Toni Merwec" <mistertorpedo@freenet.de>
Date: Fri, 16 Nov 2007 11:15:09 +0100
Links: << >>  << T >>  << A >>
Hi there,

I am currently designing an FPGA board, featuring two Xilinx Virtex-4 FPGAs. 
I've already posted another question concerning a correct JTAG chain 
implementation a few days ago and gained pretty good response. But some 
problems remain... although on another topic:

I'll be using the Xilinx Virtex-4 FX series FPGAs featuring the high-speed 
MGTs. The MGTs are located in two rows on each FPGA, each requiring their 
own MGT reference clock, i.e. four reference clock inputs have to be fed 
altogether plus at least one additional clock input for the core logic per 
FPGA. Because the FPGAs have to exchange data synchronously (via the 
standard GPIOs) I thought about using the same reference clocks for both 
FPGA and making them the same as the MGT reference. Unfortunately that leads 
to a clock signal that has to be distributed to at least 6 FPGA clock 
inputs.

I don't think that a regular low-jitter clock device (and it HAS to be 
low-jitter as for the reference for the MGTs) can drive 6 inputs over 
several centimeters. I already used the ICS843020 clock synthesizer in 
several other projects and wanted to use it again. Reason for the ICS is 
that it features a programmable output frequency in the range of 35 - 700 
MHz. Problem is, the ICS843020 has only two outputs. The Epson EG2121CA 
device that is proposed in the Virtex-4 MGT user guide is not suitable 
because these devices are restricted to one fixed frequency.

Maybe a clock buffer or multi-output clock distribution device is the 
solution here, but I am afraid every additional device in the clock network 
would introduce additional jitter which is the most critical aspect in this 
application. Therefore I woul prefer a solution without those kind of 
devices... if possible.

Has anyone ever had a similar problem and knows about an adequate solution? 
Any help (if possible) is much appreciated. Thanks!

Regards Toni






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
2019JanFebMar2019

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