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 147000

Article: 147000
Subject: Enterpoint Moving
From: John Adair <g1@enterpoint.co.uk>
Date: Fri, 9 Apr 2010 04:18:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
Enterpoint is moving it's design and sales team to a new location next
Tuesday. Expect our telephone and email service not to be up to the
usual standard for about 1 week after the move. Our website and web
shop will be unaffected by the move but shipping of items bought on
the web shop may take an extra day to ship over normal service.

Longer term the move will enable a better service from Enterpoint. We
have been seriously space constrainted over the last year and some of
our bigger product plans can now be unleashed.

John Adair
Enterpoint Ltd.

Article: 147001
Subject: Re: FMC Boards ?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Fri, 9 Apr 2010 06:51:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 7, 6:50=A0pm, Yan <yan.li...@gmail.com> wrote:
> On Mar 31, 10:04=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
>
>
>
>
> > On Mar 31, 1:51=A0am, luudee <rudolf.usselm...@gmail.com> wrote:
>
> > > Does anybody else, besides xilinx, make FMC boards for ml605 & sp605 =
?
>
> > > HW-FMC-XM105-G =A0FMC XM105 DEBUG CARD
> > > HW-FMC-XM104-G =A0FMC CONNECTIVITY MEZZANINE CARD
>
> > > Buying Xilinx products now means going through Avnet, which is a
> > > nightmare and HUGE lead times ...
>
> > > Thanks,
> > > rudi
>
> > While the XM104 is listed with a 8 week lead time on the Avnet site, I
> > know that we have these available in inventory and they will ship
> > promptly after the order is placed. =A0The XM105 is listed with a 2 wee=
k
> > lead time.
>
> > There are a number of other companies releasing FMC cards, just be
> > sure that the cards support a VADJ of 2.5V and there shouldn't be a
> > problem.
>
> > 4DSP recently announced a FMC familyhttp://www.przoom.com/news/66794/
>
> > Curtiss-Wright also has a number of boards.http://www.cwcembedded.com/0=
/62/651.html
>
> > And Xilinx has a number of other boards in pipeline to be released
> > next quarter.http://www.xilinx.com/fmc
>
> > Ed McGettigan
> > --
> > Xilinx Inc.
>
> Ed,
>
> I just board a ML605 kit and is shopping FMC daughter board. I
> understand that Xilinx worked with Analog Device on a multi-mode radio
> demo platform. Analog Devices provided a RF board called Mixed Signal
> Digital Pre-Distortion (MSDPD) board. I wonder if that board is
> available for purchase. I got the information from:
>
> http://www.xilinx.com/publications/prod_mktg/Radio-TDP-SellSheet.pdf
>
> Yan- Hide quoted text -
>
> - Show quoted text -

This FMC board was developed by Analog Devices and while I had some
involvement in the initial design phase I'm not sure what the go-to-
market strategy was for the board.  I would suggest that you use the
"Contact Wireless" team link on this page to get further information
on availability.
http://www.xilinx.com/esp/wireless.htm

Ed McGettigan
--
Xilinx Inc.

Article: 147002
Subject: Re: Debug multiple FPGAs using ChipScope via single JTAG chain
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Fri, 9 Apr 2010 06:55:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 8, 11:57=A0pm, Speed <speedboy1...@gmail.com> wrote:
> Dear All,
> =A0 We are planning to design a board with four FPGAs to emulate X86
> CPU. The FPGA=92s JTAG ports are serially chained together. My problem
> is that whether the Xilinx=92s ChipScope can support debugging multiple
> FPGAs via a single JTAG chain at the same time? So we can set
> different trigger conditions to different FPGA chips at the same time
> and watch the sampled data from ChipScope.
>
> Thanks in advance,
> Speed.

Yes, ChipScope can handle debugging in multiple FPGAs in the same
chain.  Each of the ILA cores will be independent of each other.

Ed McGettigan
--
Xilinx Inc.

Article: 147003
Subject: Can Spartan-6 Support M-LVDS ?
From: ajpanicker <rekcinapja@gmail.com>
Date: Fri, 9 Apr 2010 07:01:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
Does the Spartan-6 LX family or Spartan3A support the Multipoint-LVDS
specifications?

We need input and ouput buffers compliant to M-LVDS type1 and types
2.

Also , the buffers should be 5V LVTTL tolerant.

Article: 147004
Subject: Spartan-3 dsp FG676 Vccint decoupling caps
From: Mawa_fugo <ccon67@netscape.net>
Date: Fri, 9 Apr 2010 07:05:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
Our PCB guy saying there's no enough room for Vccint pins (all
converge at center of the chip) so that each pin has one 0.01 uF
decoupling cap.  As a result we have just 12 caps for 23 vccint
pins !!!

Wonder if anyone out there has similar pcb placement problem like us,
and how you solve it ?


TIA


Article: 147005
Subject: I'd rather switch than fight!
From: rickman <gnuarm@gmail.com>
Date: Fri, 9 Apr 2010 07:07:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
I think I have about had it with VHDL.  I've been using the
numeric_std library and eventually learned how to get around the
issues created by strong typing although it can be very arcane at
times.  I have read about a few suggestions people are making to help
with some aspects of the language, like a selection operator like
Verilog has.  But it just seems like I am always fighting some aspect
of the VHDL language.

I guess part of my frustration is that I have yet to see where strong
typing has made a real difference in my work... at least an
improvement.  My customer uses Verilog and has mentioned several times
how he had tried using VHDL and found it too arcane to bother with.
He works on a much more practical level than I often do and it seems
to work well for him.

One of my goals over the summer is to teach myself Verilog so that I
can use it as well as I currently use VHDL.  Then I can make a fully
informed decision about which I will continue to use.  I'd appreciate
pointers on good references, web or printed.

Without starting a major argument, anyone care to share their feelings
on the differences in the two languages?

Rick

Article: 147006
Subject: ISE Timing Constraints
From: "Fredxx" <fredxx@spam.com>
Date: Fri, 9 Apr 2010 15:17:08 +0100
Links: << >>  << T >>  << A >>
I seem to be stuck on this one.

I have 2 DCMS creating a 100MHz clock and a 125MHz clock derived from a 
common 25MHz clock.

Signals cross clock domains using grey-code and suitable multiple latches 
where appropriate.  I am aware of metastable states etc and their 
consequences..

However when I specify a 40ns timing criteria for the 25MHz clock I get a 
mapping failure. I increase the timing criteria to 80ns and the timing 
analysis is expecting clock transitions at 16 and 20ns, for signals crossing 
clock domains which of course it fails.  How can I turn off timing analysis 
for signals crossing clock domains?  I note that the "TIG" can't be used for 
"from" "to" statements.



Article: 147007
Subject: Re: Spartan-3 dsp FG676 Vccint decoupling caps
From: Mawa_fugo <ccon67@netscape.net>
Date: Fri, 9 Apr 2010 07:26:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 9:05=A0am, Mawa_fugo <cco...@netscape.net> wrote:
> Our PCB guy saying there's no enough room for Vccint pins (all
> converge at center of the chip) so that each pin has one 0.01 uF
> decoupling cap. =A0As a result we have just 12 caps for 23 vccint
> pins !!!
>
> Wonder if anyone out there has similar pcb placement problem like us,
> and how you solve it ?
>
> TIA

btw, those caps are in 402 package,

Article: 147008
Subject: Re: I'd rather switch than fight!
From: Andy <jonesandy@comcast.net>
Date: Fri, 9 Apr 2010 07:50:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
Before the fixed and floating point packages came out, I would have
said there is little difference regarding RTL capabilities between
Verilog and VHDL. But those two packages revealed a fundamental
strength of VHDL that simply does not exist in verilog. By simply
writing a new package, a whole new capability was created that would
take a substantial language change in Verilog. Yes, the as-released
packages took advantage of features only available in a related change
in the language itself, but the "compatibility" packages ably
demonstrate that the working concept is viable even within the
confines the original language, thus demonstrating the true strengh of
the basic language of VHDL.

Not that the fixed/floating point packages are nirvana, but they do
represent a huge step in the right direction. If we only had
assignment operator overloading in VHDL, it would be much closer...
Still, that's a capability much closer to reality in VHDL than in
Verilog. Sure, verilog has many "built-in" tricks, but they are only
applicable to the existing type structure, and cannot be expanded upon
without revising the language itself.

Even before the fixed/floating point packages, integers simply work in
VHDL (within the range limitations), whereas in Verilog, they don't
always, but they also don't complain when they don't work either.

In general, strong typing and built-in bounds checking in VHDL catch
more problems, closer to the source of the problems, with no
additional code being written, than is possible in Verilog without
having to write A LOT of extra code. It seems for almost every weak-
typing-enabled shortcut in verilog, there is also a hidden, often
silent, "gotcha" to go along with it.

Andy

Article: 147009
Subject: Re: ISE Timing Constraints
From: austin <austin@xilinx.com>
Date: Fri, 9 Apr 2010 07:53:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
f,

This is your lucky day:

Go read my new blog post:

http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/ba-p/66696

where TIG is discussed, and an example given how it can be used in a
FROM-TO.

Since this design is completely synchronous to the 25 MHz clock, if
properly constrained (and designed) there will be metastability issues
at all.

Your Gray code and synchronizers may not be necessary at all.
However, if you don't have the time (or knowledge) to do this
properly, then having a two clocks that are almost (but not quite)
synchronous can be a nightmare, and no amount of Gary coded counters,
nor synchronizers will save you:  you will be "almost always at the
wrong point" so frequently that you have created the perfect storm for
looking at metastable events.

The built in BRAM FIFO in V5 and V6 is the obvious solution to cross
boundaries, or the use of a FIFO from the core generator, is
suggested:  do not try to spin your own solution unless you are an
expert in clock domain crossing -- this is not for "newbies" to try
(unless they are trying to develop the skills to do it right).

You would be better off using the 125 MHz clock domain everywhere, and
creating a clock enable that disables one 125 clock out of every five
125 clocks (for the 100 MHz domain processing).  Then you will have no
need to cross any clock boundaries, the design is simpler, more
robust, and will likely just work.

If you then need to transfer data out at 100 MHz, that is where the
FIFO is best used:  once, at this boundary.  The same is not true for
transferring 100 MHz data into the 125 MHz domain, that is
accomplished by just sampling at the right time (the four clocks not
dropped every 5).

Austin

Article: 147010
Subject: Re: Spartan-3 dsp FG676 Vccint decoupling caps
From: Symon <symon_brewer@hotmail.com>
Date: Fri, 09 Apr 2010 15:59:34 +0100
Links: << >>  << T >>  << A >>
On 4/9/2010 3:26 PM, Mawa_fugo wrote:
> On Apr 9, 9:05 am, Mawa_fugo<cco...@netscape.net>  wrote:
>> Our PCB guy saying there's no enough room for Vccint pins (all
>> converge at center of the chip) so that each pin has one 0.01 uF
>> decoupling cap.  As a result we have just 12 caps for 23 vccint
>> pins !!!
>>
>> Wonder if anyone out there has similar pcb placement problem like us,
>> and how you solve it ?
>>
>> TIA
>
> btw, those caps are in 402 package,

Fit them on the backside from the FPGA. Use round pads on the 0402 caps 
so they fit in between the via array.

Better still, ignore Xilinx's ridiculously conservative recommendations 
and design it properly.

http://www.x2y.com/bypass/mount/backside_cap.pdf

HTH, Syms.



Article: 147011
Subject: Re: Can Spartan-6 Support M-LVDS ?
From: austin <austin@xilinx.com>
Date: Fri, 9 Apr 2010 08:05:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
a,

If it is not in the data sheet, then it isn't supported.

I have no idea what "multi-point" LVDS is:  sounds like someone's idea
of how to ruin a perfectly good point to point IEEE standard!

OK, I just read about it on Wikipedia, and that confirms my
suspicions ...

There is the "bus-LVDS" which we 'invented' and supported, but the
signal integrity of that is a compromise at best, and I have never
really liked to deal with it at all.  Regardless, it does work (within
its limits).

For 5v tolerance, I suggest level shifters, or using resistors.  At
these advanced technology nodes we are lucky to be able to still use
3.3v IO!

Austin


Article: 147012
Subject: Problems with data2mem
From: Falk Brunner <falk.brunner@gmx.de>
Date: Fri, 9 Apr 2010 08:08:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello everybody,

long time no see. ;-)

Now that I return to FPGA design at least for hobby purposes, I have
some trouble with data2mem. Iam using Webpack 11.1. I want to use
Picoblaze in a Spartan 3A 700. For updating of the program memory I
use data2mem, but without success. :-(

Here is my bmm file

ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x09FF]
	BUS_BLOCK
		bram0 [15:0] LOC =X0Y0;
	END_BUS_BLOCK;
END_ADDRESS_SPACE;


here my command line for data2mem

data2mem -i -bm ..\pico.bmm -bd pico_bas.mem -bt ..\top_picoblaze.bit -
ob ..\top_picoblaze_prog.bit

When I do so, I get the following error message

ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
'ROM_SPACE'.
    ADDRESS_SPACE was defined as 0x00000A00 bytes, but the
ADDRESS_RANGE total is 0x00000800 bytes.

When I change the definition in the BMM file to

ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x07FF]
	BUS_BLOCK
		bram0 [15:0] LOC =X0Y0;
	END_BUS_BLOCK;
END_ADDRESS_SPACE;

I get this error.

ERROR:Data2MEM:31 - Out of bounds code segment for ram space in '..
\pico.bmm'.
    Memory space 'ROM_SPACE' occupies [0x00000000:0x000007FF]
    Code segment #0 occupies [0x00000000:0x000009FF]

The documentation of data2mem is sometimes confusing. At one place it
says there is only RAMB16 for Spartan 3, at another line it says
RAMB18 is available for Spartan 3.

Also using RAMB18 does not work.

ADDRESS_SPACE ROM_SPACE RAMB18 [0x0000:0x07FF]
	BUS_BLOCK
		bram0 [17:0] LOC =X0Y0;
	END_BUS_BLOCK;
END_ADDRESS_SPACE;

ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
'ROM_SPACE'.

    ADDRESS_SPACE was defined as 0x00000800 bytes, but the
ADDRESS_RANGE total is 0x00000900 bytes.

Any hint is appreciated.

Regards
Falk

Article: 147013
Subject: Re: Spartan-3 dsp FG676 Vccint decoupling caps
From: John Adair <g1@enterpoint.co.uk>
Date: Fri, 9 Apr 2010 08:23:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
It's basically impossible to do on a cost effective board. In practise
you can get away with a lot less of them if you planes are done well
and paired properly with a ground plane. Array capacitors we also use
a lot for density and you can see those on all of our development
boards for Spartan-3 etc.

John Adair
Enterpoint Ltd.


On 9 Apr, 15:05, Mawa_fugo <cco...@netscape.net> wrote:
> Our PCB guy saying there's no enough room for Vccint pins (all
> converge at center of the chip) so that each pin has one 0.01 uF
> decoupling cap. =A0As a result we have just 12 caps for 23 vccint
> pins !!!
>
> Wonder if anyone out there has similar pcb placement problem like us,
> and how you solve it ?
>
> TIA


Article: 147014
Subject: Re: ISE Timing Constraints
From: "Fredxx" <fredxx@spam.com>
Date: Fri, 9 Apr 2010 16:45:58 +0100
Links: << >>  << T >>  << A >>

"austin" <austin@xilinx.com> wrote in message 
news:fc92c4bb-3a00-4990-b2f5-3767c15c41c9@x20g2000yqb.googlegroups.com...
> f,
>
> This is your lucky day:
>
> Go read my new blog post:
>
> http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/ba-p/66696
>
> where TIG is discussed, and an example given how it can be used in a
> FROM-TO.
>
> Since this design is completely synchronous to the 25 MHz clock, if
> properly constrained (and designed) there will be metastability issues
> at all.
>
> Your Gray code and synchronizers may not be necessary at all.
> However, if you don't have the time (or knowledge) to do this
> properly, then having a two clocks that are almost (but not quite)
> synchronous can be a nightmare, and no amount of Gary coded counters,
> nor synchronizers will save you:  you will be "almost always at the
> wrong point" so frequently that you have created the perfect storm for
> looking at metastable events.
>
> The built in BRAM FIFO in V5 and V6 is the obvious solution to cross
> boundaries, or the use of a FIFO from the core generator, is
> suggested:  do not try to spin your own solution unless you are an
> expert in clock domain crossing -- this is not for "newbies" to try
> (unless they are trying to develop the skills to do it right).
>
> You would be better off using the 125 MHz clock domain everywhere, and
> creating a clock enable that disables one 125 clock out of every five
> 125 clocks (for the 100 MHz domain processing).  Then you will have no
> need to cross any clock boundaries, the design is simpler, more
> robust, and will likely just work.
>
> If you then need to transfer data out at 100 MHz, that is where the
> FIFO is best used:  once, at this boundary.  The same is not true for
> transferring 100 MHz data into the 125 MHz domain, that is
> accomplished by just sampling at the right time (the four clocks not
> dropped every 5).
>
> Austin

Many thanks, I had made a syntax error where I wrote

TIMESPEC "my_fromto" = FROM "my_from_grp" TO "my_to_grp" TIG;

and when changed ito

TIMESPEC TS_my_fromto = FROM "my_from_grp" TO "my_to_grp" TIG;

it all worked.

I'm sure in my past designs I haven't had this problem, but I guess using 
clocks which have a common sourse means that the timing analyser has founf 
something to analyse!

I take your point about the sourcing of clocks.  For various reasons I want 
the design to be flexible as possible, and willing to accept the 
consequences.  Also missing a clock every 5 will require a tighter design in 
terms of timing. 



Article: 147015
Subject: Re: Spartan-3 dsp FG676 Vccint decoupling caps
From: Mawa_fugo <ccon67@netscape.net>
Date: Fri, 9 Apr 2010 09:04:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 10:23=A0am, John Adair <g...@enterpoint.co.uk> wrote:
> It's basically impossible to do on a cost effective board. In practise
> you can get away with a lot less of them if you planes are done well
> and paired properly with a ground plane. Array capacitors we also use
> a lot for density and you can see those on all of our development
> boards for Spartan-3 etc.
>
> John Adair
> Enterpoint Ltd.
>
> On 9 Apr, 15:05, Mawa_fugo <cco...@netscape.net> wrote:
>
> > Our PCB guy saying there's no enough room for Vccint pins (all
> > converge at center of the chip) so that each pin has one 0.01 uF
> > decoupling cap. =A0As a result we have just 12 caps for 23 vccint
> > pins !!!
>
> > Wonder if anyone out there has similar pcb placement problem like us,
> > and how you solve it ?
>
> > TIA
>
>

I found this ug454, about the development board using the same part

http://www.xilinx.com/support/documentation/boards_and_kits/ug454_sp3a_dsp_=
start_ug.pdf

Page 56 they're talking about the ladder caps for Vccint 1.2V,
there're 13 caps of 0.01 and several other values, makes up total of
25 caps.  There's no footprint image for them !!

I guess, just the 13 high speed caps are placed on the back of the
chip, right at the via - impossible to place bigger caps in that area

Wonder if someone has the image of the bottom of this board ?

TIA






Article: 147016
Subject: Re: Problems with data2mem
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 9 Apr 2010 09:39:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 10:08=A0am, Falk Brunner <falk.brun...@gmx.de> wrote:
> Hello everybody,
>
> long time no see. ;-)
>
> Now that I return to FPGA design at least for hobby purposes, I have
> some trouble with data2mem. Iam using Webpack 11.1. I want to use
> Picoblaze in a Spartan 3A 700. For updating of the program memory I
> use data2mem, but without success. :-(
>
> Here is my bmm file
>
> ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x09FF]
> =A0 =A0 =A0 =A0 BUS_BLOCK
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bram0 [15:0] LOC =3DX0Y0;
> =A0 =A0 =A0 =A0 END_BUS_BLOCK;
> END_ADDRESS_SPACE;
>
> here my command line for data2mem
>
> data2mem -i -bm ..\pico.bmm -bd pico_bas.mem -bt ..\top_picoblaze.bit -
> ob ..\top_picoblaze_prog.bit
>
> When I do so, I get the following error message
>
> ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
> 'ROM_SPACE'.
> =A0 =A0 ADDRESS_SPACE was defined as 0x00000A00 bytes, but the
> ADDRESS_RANGE total is 0x00000800 bytes.
>
> When I change the definition in the BMM file to
>
> ADDRESS_SPACE ROM_SPACE RAMB16 [0x0000:0x07FF]
> =A0 =A0 =A0 =A0 BUS_BLOCK
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bram0 [15:0] LOC =3DX0Y0;
> =A0 =A0 =A0 =A0 END_BUS_BLOCK;
> END_ADDRESS_SPACE;
>
> I get this error.
>
> ERROR:Data2MEM:31 - Out of bounds code segment for ram space in '..
> \pico.bmm'.
> =A0 =A0 Memory space 'ROM_SPACE' occupies [0x00000000:0x000007FF]
> =A0 =A0 Code segment #0 occupies [0x00000000:0x000009FF]
>
> The documentation of data2mem is sometimes confusing. At one place it
> says there is only RAMB16 for Spartan 3, at another line it says
> RAMB18 is available for Spartan 3.
>
> Also using RAMB18 does not work.
>
> ADDRESS_SPACE ROM_SPACE RAMB18 [0x0000:0x07FF]
> =A0 =A0 =A0 =A0 BUS_BLOCK
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bram0 [17:0] LOC =3DX0Y0;
> =A0 =A0 =A0 =A0 END_BUS_BLOCK;
> END_ADDRESS_SPACE;
>
> ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
> 'ROM_SPACE'.
>
> =A0 =A0 ADDRESS_SPACE was defined as 0x00000800 bytes, but the
> ADDRESS_RANGE total is 0x00000900 bytes.
>
> Any hint is appreciated.
>
> Regards
> Falk

You didn't show your mem file, but if it starts at, e.g. 0x200, and is
0x800 long, that could explain that sort of error.  You would fix that
by using a space like [0x200:0x9FF].

Regards,
Pat

Article: 147017
Subject: Re: I'd rather switch than fight!
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 9 Apr 2010 09:53:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 9:07=A0am, rickman <gnu...@gmail.com> wrote:
> I think I have about had it with VHDL. =A0I've been using the
> numeric_std library and eventually learned how to get around the
> issues created by strong typing although it can be very arcane at
> times. =A0I have read about a few suggestions people are making to help
> with some aspects of the language, like a selection operator like
> Verilog has. =A0But it just seems like I am always fighting some aspect
> of the VHDL language.
>
> I guess part of my frustration is that I have yet to see where strong
> typing has made a real difference in my work... at least an
> improvement. =A0My customer uses Verilog and has mentioned several times
> how he had tried using VHDL and found it too arcane to bother with.
> He works on a much more practical level than I often do and it seems
> to work well for him.
>
> One of my goals over the summer is to teach myself Verilog so that I
> can use it as well as I currently use VHDL. =A0Then I can make a fully
> informed decision about which I will continue to use. =A0I'd appreciate
> pointers on good references, web or printed.
>
> Without starting a major argument, anyone care to share their feelings
> on the differences in the two languages?
>
> Rick

The best online references are the Sutherland Verilog references.
There is an online HTML reference for Verilog 95 (excellent), and a
PDF for Verilog 2001 (good):

http://www.sutherland-hdl.com/online_verilog_ref_guide/vlog_ref_top.html
http://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_guide.p=
df

Cliff Cummings has a lot of good papers on Verilog at his site:

http://sunburst-design.com/papers/

In particular, if you read and carefully grok his paper about non-
blocking vs. blocking assignments, you will be well on your way to
being a Verilog wizard:

http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf

Regards,
Pat

Article: 147018
Subject: Re: Can Spartan-6 Support M-LVDS ?
From: Eric Smith <spacewar@gmail.com>
Date: Fri, 9 Apr 2010 10:08:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Also , the buffers should be 5V LVTTL tolerant.

Which?  5V, or LVTTL?  They are two different things.

IIRC, Spartan-6 does support LVTTL.  It does not support 5V I/O
directly.

Article: 147019
Subject: Re: Problems with data2mem
From: Falk Brunner <falk.brunner@gmx.de>
Date: Fri, 9 Apr 2010 10:43:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 9 Apr., 18:39, Patrick Maupin <pmau...@gmail.com> wrote:

> You didn't show your mem file, but if it starts at, e.g. 0x200, and is
> 0x800 long, that could explain that sort of error. =A0You would fix that
> by using a space like [0x200:0x9FF].

Its pretty simple, it starts with @00000000, followed by 1024 lines of
five digit hex numbers, representing the 18 Bit Opcodes of Picoblaze.

Regards
Falk

Article: 147020
Subject: Re: Problems with data2mem
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 9 Apr 2010 10:55:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 12:43=A0pm, Falk Brunner <falk.brun...@gmx.de> wrote:
> On 9 Apr., 18:39, Patrick Maupin <pmau...@gmail.com> wrote:
>
> > You didn't show your mem file, but if it starts at, e.g. 0x200, and is
> > 0x800 long, that could explain that sort of error. =A0You would fix tha=
t
> > by using a space like [0x200:0x9FF].
>
> Its pretty simple, it starts with @00000000, followed by 1024 lines of
> five digit hex numbers, representing the 18 Bit Opcodes of Picoblaze.
>
> Regards
> Falk

Well, in that case, it's 17:0, not 15:0, for the width, no?

Regards,
Pat

Article: 147021
Subject: Re: Problems with data2mem
From: Patrick Maupin <pmaupin@gmail.com>
Date: Fri, 9 Apr 2010 10:58:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 12:55=A0pm, Patrick Maupin <pmau...@gmail.com> wrote:
> On Apr 9, 12:43=A0pm, Falk Brunner <falk.brun...@gmx.de> wrote:
>
> > On 9 Apr., 18:39, Patrick Maupin <pmau...@gmail.com> wrote:
>
> > > You didn't show your mem file, but if it starts at, e.g. 0x200, and i=
s
> > > 0x800 long, that could explain that sort of error. =A0You would fix t=
hat
> > > by using a space like [0x200:0x9FF].
>
> > Its pretty simple, it starts with @00000000, followed by 1024 lines of
> > five digit hex numbers, representing the 18 Bit Opcodes of Picoblaze.
>
> > Regards
> > Falk
>
> Well, in that case, it's 17:0, not 15:0, for the width, no?
>
> Regards,
> Pat

Oh, I see what you mean.  I've never used the parity bits, so I don't
know how that works.

Article: 147022
Subject: Re: ISE Timing Constraints
From: Gabor <gabor@alacron.com>
Date: Fri, 9 Apr 2010 11:06:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 11:45=A0am, "Fredxx" <fre...@spam.com> wrote:
> "austin" <aus...@xilinx.com> wrote in message
>
> news:fc92c4bb-3a00-4990-b2f5-3767c15c41c9@x20g2000yqb.googlegroups.com...
>
>
>
> > f,
>
> > This is your lucky day:
>
> > Go read my new blog post:
>
> >http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/b...
>
> > where TIG is discussed, and an example given how it can be used in a
> > FROM-TO.
>
> > Since this design is completely synchronous to the 25 MHz clock, if
> > properly constrained (and designed) there will be metastability issues
> > at all.
>
> > Your Gray code and synchronizers may not be necessary at all.
> > However, if you don't have the time (or knowledge) to do this
> > properly, then having a two clocks that are almost (but not quite)
> > synchronous can be a nightmare, and no amount of Gary coded counters,
> > nor synchronizers will save you: =A0you will be "almost always at the
> > wrong point" so frequently that you have created the perfect storm for
> > looking at metastable events.
>
> > The built in BRAM FIFO in V5 and V6 is the obvious solution to cross
> > boundaries, or the use of a FIFO from the core generator, is
> > suggested: =A0do not try to spin your own solution unless you are an
> > expert in clock domain crossing -- this is not for "newbies" to try
> > (unless they are trying to develop the skills to do it right).
>
> > You would be better off using the 125 MHz clock domain everywhere, and
> > creating a clock enable that disables one 125 clock out of every five
> > 125 clocks (for the 100 MHz domain processing). =A0Then you will have n=
o
> > need to cross any clock boundaries, the design is simpler, more
> > robust, and will likely just work.
>
> > If you then need to transfer data out at 100 MHz, that is where the
> > FIFO is best used: =A0once, at this boundary. =A0The same is not true f=
or
> > transferring 100 MHz data into the 125 MHz domain, that is
> > accomplished by just sampling at the right time (the four clocks not
> > dropped every 5).
>
> > Austin
>
> Many thanks, I had made a syntax error where I wrote
>
> TIMESPEC "my_fromto" =3D FROM "my_from_grp" TO "my_to_grp" TIG;
>
> and when changed ito
>
> TIMESPEC TS_my_fromto =3D FROM "my_from_grp" TO "my_to_grp" TIG;
>
> it all worked.
>
> I'm sure in my past designs I haven't had this problem, but I guess using
> clocks which have a common sourse means that the timing analyser has foun=
f
> something to analyse!
>
> I take your point about the sourcing of clocks. =A0For various reasons I =
want
> the design to be flexible as possible, and willing to accept the
> consequences. =A0Also missing a clock every 5 will require a tighter desi=
gn in
> terms of timing.

It always bothered me that time specs needed to start with "TS".  This
is the syntax problem in the first version, not the quotes.


Article: 147023
Subject: Re: Problems with data2mem
From: Falk Brunner <falk.brunner@gmx.de>
Date: Fri, 9 Apr 2010 11:06:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
Argrr, I have a STRANGE feeling.

Since I use the RAM in 18 Bits width, every data word ist 5 hex digits
long, which is 2.25 bytes. Times 1024 equals 2304 Bytes, which is
0x900.
I guess data2mem is confused by the 18 bit data width . . .
It calculates the number of nibbles instead the number of 18 bit
words.

    ADDRESS_SPACE was defined as 0x00000800 bytes, but the
ADDRESS_RANGE total is 0x00000900 bytes.

0x800 = 2048 Words with 16 Bits each
0x900 = 2304 = 2048 + 256 Words with 18 Bits each

Looks like another ISE bug . . . :-(

Article: 147024
Subject: Re: I'd rather switch than fight!
From: gabor <gabor@alacron.com>
Date: Fri, 9 Apr 2010 11:25:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 10:07=A0am, rickman <gnu...@gmail.com> wrote:
> I think I have about had it with VHDL. =A0I've been using the
> numeric_std library and eventually learned how to get around the
> issues created by strong typing although it can be very arcane at
> times. =A0I have read about a few suggestions people are making to help
> with some aspects of the language, like a selection operator like
> Verilog has. =A0But it just seems like I am always fighting some aspect
> of the VHDL language.
>
> I guess part of my frustration is that I have yet to see where strong
> typing has made a real difference in my work... at least an
> improvement. =A0My customer uses Verilog and has mentioned several times
> how he had tried using VHDL and found it too arcane to bother with.
> He works on a much more practical level than I often do and it seems
> to work well for him.
>
> One of my goals over the summer is to teach myself Verilog so that I
> can use it as well as I currently use VHDL. =A0Then I can make a fully
> informed decision about which I will continue to use. =A0I'd appreciate
> pointers on good references, web or printed.
>
> Without starting a major argument, anyone care to share their feelings
> on the differences in the two languages?
>
> Rick

At the end of the day, it really comes down to how you can be more
productive.  If you tend to code with many levels of abstraction
you may do better with VHDL.  I find that I am more productive
with Verilog, but it could be because I tend to look at hardware
at a fairly detailed level, a bottom-up approach if you will.  I
inherited Verilog projects at my current place of employment and
just stuck with the language as it grew on me.  At one point I
read Thomas & Moorby's green book from cover to cover.  However
it described Verilog 95, not the more commonly used Verilog 2001,
and was not a particularly good reference book.  I keep a copy
of the Doulos Golden Reference handy for the bits I don't use
every day.

Good Luck,
Gabor



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