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 143175

Article: 143175
Subject: Virtex 4 configruation frame internal details
From: "intermilan" <wenweizha@gmail.com>
Date: Thu, 24 Sep 2009 08:56:42 -0500
Links: << >>  << T >>  << A >>
Given Top_Bot bit, Block Type (say CLB), Row addre, column addr and minor
addr, the address of configuration frame is fixed.

However, inside this frame, there are 41 words. Is there any document that
describe the frame bits details?

For example, in V4FX60, CLB of tile offset X57Y127 has Top_B Bit = 0,
Block Type = 0, Row Addr = 3, Column Addr = 51, Minor Addr = 19. Slice
X90Y254 is in this CLB. How can I find which word in this frame is
corresponding to the F LUT of Slice X90Y254?

thanks



Article: 143176
Subject: Re: USB programmable Open Source Hardware
From: nobody <cydrollinger@gmail.com>
Date: Thu, 24 Sep 2009 07:30:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rick,

You were right, I can not refute you at this time it is $6.10 per
board so it stands no one can do it for $6 a board. Yes, they do a
minimum of $50.00. Still that seems good, no that seems great!

Cy

From matthieu.d.u.m.m.y.michon@gmail.com Thu Sep 24 08:39:55 2009
Path: unlimited.newshosting.com!s02-b86!num01.iad!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!cleanfeed2-a.proxad.net!nnrp6-2.free.fr!not-for-mail
Date: Thu, 24 Sep 2009 17:39:55 +0200
From: Matthieu Michon <matthieu.d.u.m.m.y.michon@gmail.com>
Newsgroups: comp.arch.fpga
Subject: Re: Xilinx XST and counter synthesis problem
Message-Id: <20090924173955.0a626032.matthieu.d.u.m.m.y.michon@gmail.com>
References: <0cf0b35f-6680-48c2-9b45-21f758b37679@e34g2000vbm.googlegroups.com>
	<7hsjjqF2udr0gU1@mid.individual.net>
	<cfbc382f-65b6-4eb5-8077-5514eac8e0a2@r36g2000vbn.googlegroups.com>
	<8b4f03ad-0c13-4525-a3ee-174b10c219bc@s6g2000vbp.googlegroups.com>
	<7f37472c-26d3-40b9-9ef9-07d60fb5a9ef@o35g2000vbi.googlegroups.com>
	<2f4558a6-ad91-406c-871c-d9b90b3b27a3@p23g2000vbl.googlegroups.com>
X-Newsreader: Sylpheed 2.7.1 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 30
Organization: Guest of ProXad - France
NNTP-Posting-Date: 24 Sep 2009 17:39:54 MEST
NNTP-Posting-Host: 213.215.9.6
X-Trace: 1253806794 news-3.free.fr 4968 213.215.9.6:50158
X-Complaints-To: abuse@proxad.net
Xref: unlimited.newshosting.com comp.arch.fpga:93821
X-Received-Date: Thu, 24 Sep 2009 15:39:55 UTC (s02-b86)

On Thu, 24 Sep 2009 01:28:11 -0700 (PDT)
"nic_o_mat@msn.com" <nic_o_mat@msn.com> wrote:

> (...)
> I always use an asynchronous reset description in my processes but the
> actual reset signal is synchronized in another block.
> I only posted the offending entity, the design is larer than this
> single file.
> 
> I am no beginner and I did simulate my design before synthesizing it.
> Simulation runs absolutely fine.
> I have made further investigation, the SPI master generates the
> correct number of clock cycles but only the 12 first bits are
> transmitted, MOSI then goes high.
> 
> Nicolas


In the case of a discrepancy in the behavior between simulation and execution, I would check the usuals :
 - Synthesis and implementation transcript for anything even remotely suspicious (while focusing manly on the logic optimization and timing).
 - Reset signal synchronization is performed against the _correct_ clock net.
 - RTL and physical (low-level) FPGA implementation of your design.

While you may not have access to the JTAG interface of the FPGA (o/w I guess you'd already have used chipscope to probe the revelant nets), you can always throw a post p/r simulation, just to make sure that the toolchain didn't caught its feet in the rug while implementing your design.


Hope this helps.

-- 
Matthieu Michon

Article: 143177
Subject: Re: Virtex 4 configruation frame internal details
From: austin <austin@xilinx.com>
Date: Thu, 24 Sep 2009 08:53:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
im,

Why? ( I am curious)

One easy way to find things is to use FPGA_editor to create two
identical designs, with different logic equations in the LUT of
interest.  Use "diff" (or equivalent) to find the difference in the
two bitstreams.

Austin

Article: 143178
Subject: Re: USB programmable Open Source Hardware
From: "Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com>
Date: Thu, 24 Sep 2009 09:10:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 24, 5:30=A0pm, nobody <cydrollin...@gmail.com> wrote:
> Rick,
>
> You were right, I can not refute you at this time it is $6.10 per
> board so it stands no one can do it for $6 a board. Yes, they do a
> minimum of $50.00. Still that seems good, no that seems great!
>
> Cy

min order 50$ no setup fee for 4 layer?
and free shipping?

this is pretty good if so

Antti

Article: 143179
Subject: Re: Virtex 4 configruation frame internal details
From: "Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com>
Date: Thu, 24 Sep 2009 09:11:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 24, 6:53=A0pm, austin <aus...@xilinx.com> wrote:
> im,
>
> Why? ( I am curious)
>
> One easy way to find things is to use FPGA_editor to create two
> identical designs, with different logic equations in the LUT of
> interest. =A0Use "diff" (or equivalent) to find the difference in the
> two bitstreams.
>
> Austin

hm if that is the easy way, what is the hard way?

Antti

Article: 143180
Subject: Re: Virtex 4 configruation frame internal details
From: Ulrich Langenbach <ulrich@falaba.de>
Date: Thu, 24 Sep 2009 20:54:59 +0200
Links: << >>  << T >>  << A >>
Hello!

> For example, in V4FX60, CLB of tile offset X57Y127 has Top_B Bit = 0,
> Block Type = 0, Row Addr = 3, Column Addr = 51, Minor Addr = 19. Slice
> X90Y254 is in this CLB. How can I find which word in this frame is
> corresponding to the F LUT of Slice X90Y254?

I don't think that there is an official document, because this would reveal 
some technological information about the structure of their devices Xilinx 
likes to keep secret, BUT, there was a project able to somehow dissassamble 
the bitstream: http://www.ulogic.org. Maybe it provides the information you 
have been looking for.

Regards,

Ulrich Langenbach



Article: 143181
Subject: Re: Virtex 4 configruation frame internal details
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 24 Sep 2009 21:03:27 +0200
Links: << >>  << T >>  << A >>
Antti.Lukats@googlemail.com wrote:

> hm if that is the easy way, what is the hard way?

The hard way would be to use two different VHDL files and compare the
bitstreams :-)

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 143182
Subject: Re: Shift left arithmetic?
From: rickman <gnuarm@gmail.com>
Date: Thu, 24 Sep 2009 15:04:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 23, 6:11=A0pm, Mike Treseler <mtrese...@gmail.com> wrote:
> > On Sep 23, 7:56 pm, rickman <gnu...@gmail.com> wrote:
> >> I was looking up the shift operator in VHDL since I seldom use it and
> >> saw that there is both a shift left logical and a shift left
> >> arithmetic. =A0The logic shift left shifts in zeros and the arithmetic
> >> shift left shifts in the value of the lsb.
>
> sla shifts left and copies the right bit.
>
> Use of sla and sll on std_logic_vector is depreciated since
> numeric_standard.shift_left automatically does the
> "right thing" with the edge bits for signed or unsigned types.
>
> Antti.Luk...@googlemail.com wrote:
> > how is this related to FPGA?
>
> VHDL is a popular design entry language for FPGAs.
> Up until today, short verilog and vhdl questions
> have been tolerated in comp.arch.fpga.

Actually, my question is not about VHDL, it is about the utility of a
left shift operator that copies the lsb.  Or perhaps I should say the
rightmost bit.  As HK pointed out, the right bit and the lsb are not
always synonymous.  So I guess that answers my question of why this
operator might be used.  I have a bias for lsb being the "right hand"
bit as well as the zeroth bit.

I remember working with CDC documentation that used 0 to label the msb
(on the left).  That was the first time I had seen bits numbered that
way and thought these guys must be pretty strange.  I still have not
seen an explanation of why that convention would be adopted, but then
the limeys all drive on the left too!  So go figure!

I would suggest that FPGAs enforce rightmost bits being the lsb as
well as labeled with a 0.  That can be done in hardware, right?  ;^)

But you suggest that I should use instead the numeric standard
function shift_left as it does  the "right thing" for both types of
operands.  I see that there is little difference between shift_left
and sll.

  function SHIFT_LEFT (ARG: UNSIGNED; COUNT: NATURAL) return UNSIGNED;
  -- Result subtype: UNSIGNED(ARG'LENGTH-1 downto 0)
  -- Result: Performs a shift-left on an UNSIGNED vector COUNT times.
  --         The vacated positions are filled with '0'.
  --         The COUNT leftmost elements are lost.

  function SHIFT_LEFT (ARG: SIGNED; COUNT: NATURAL) return SIGNED;
  -- Result subtype: SIGNED(ARG'LENGTH-1 downto 0)
  -- Result: Performs a shift-left on a SIGNED vector COUNT times.
  --         The vacated positions are filled with '0'.
  --         The COUNT leftmost elements are lost.


It seems to be that they are doing the same thing...  In fact, the one
difference you might expect if you were using a singed operand is to
not clobber the sign bit, but that is not prevented.  So I fail to see
why shift_left would have been added to the standard.  Again, I expect
if they were adding a shift_right, they needed a shift_left to fill
the hole.  In contrast the right_shift operator does handle the sign
bit.  I think someone fell down on the job with this one... or maybe
not.  If the result of a left shift on a signed number changes the
sign bit, it would be an overflow anyway.  So I guess it's all good!

Rick

Article: 143183
Subject: Re: Shift left arithmetic?
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 24 Sep 2009 15:28:39 -0700
Links: << >>  << T >>  << A >>
rickman wrote:

> It seems to be that they are doing the same thing...

It depends on the type of arg:

     -- Id: S.1
   function shift_left  (  ARG: UNSIGNED; COUNT: NATURAL) return UNSIGNED;
      -- Result subtype: UNSIGNED (ARG'LENGTH-1 downto 0)
      -- Result: Performs a shift-left on an UNSIGNED vector COUNT times.
      --         The vacated positions are filled with Bit '0'.
      -- The COUNT leftmost bits are lost.



      -- Id: S.3
   function shift_left  (  ARG: SIGNED; COUNT: NATURAL) return SIGNED;
      -- Result subtype: SIGNED (ARG'LENGTH-1 downto 0)
      -- Result: Performs a shift-left on a SIGNED vector COUNT times.
      --    All bits of ARG, except ARG'LEFT, are shifted left COUNT times.
      --         The vacated positions are filled with Bit '0'.
      --         The COUNT leftmost bits, except ARG'LEFT, are lost.
                                          ----------------

Article: 143184
Subject: Re: Shift left arithmetic?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 24 Sep 2009 22:32:06 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
< On Sep 23, 6:11?pm, Mike Treseler <mtrese...@gmail.com> wrote:
(snip)

<> sla shifts left and copies the right bit.
(snip) 

< Actually, my question is not about VHDL, it is about the utility of a
< left shift operator that copies the lsb.  Or perhaps I should say the
< rightmost bit.  

I do agree that is unusual, at least as an arithmetic operation.

< As HK pointed out, the right bit and the lsb are not
< always synonymous.  So I guess that answers my question of why this
< operator might be used.  I have a bias for lsb being the "right hand"
< bit as well as the zeroth bit.

I only have verilog references, and have only written verilog.
I can usually read VHDL, though.

Verilog allows one to number the bits in either order.

reg [3:0] i;
reg [0:3] j;

If you assign between such, the assignment is in left to
right order, not in numerical order.
 
< I remember working with CDC documentation that used 0 to label the msb
< (on the left).  That was the first time I had seen bits numbered that
< way and thought these guys must be pretty strange.  I still have not
< seen an explanation of why that convention would be adopted, but then
< the limeys all drive on the left too!  So go figure!

IBM S/360 and successor (and probably predecessors) numbers the
MSB as bit 0.  That is consistent with big endian byte order.
(Some IBM processors were pretty much bit addressable, so that
could have been important.  S/360 is not, so the convention is
only in the documentation.)  It made things interesting with the
64 bit extension of z/Architecture.  32 bit instructions operate
on the low half of the 64 bit registers, now bits 32 to 63.
 
< I would suggest that FPGAs enforce rightmost bits being the lsb as
< well as labeled with a 0.  That can be done in hardware, right?  ;^)

That is a strange comment.  FPGAs don't enforce anything.  One can
number (or letter) the bits anyway one wants, the FPGA just supplying
a collection of logic.  I don't know about VHDL but, as I said,
verilog does not force one convention or the other.

-- glen 

Article: 143185
Subject: Re: Shift left arithmetic?
From: Andy <jonesandy@comcast.net>
Date: Thu, 24 Sep 2009 16:11:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
The VHDL numeric_std package does not force bit 0 = LSB. 'Left is
always MSB.

Not sure about the new fixed point types...

Andy

Article: 143186
Subject: Re: Shift left arithmetic?
From: gavin@allegro.com (Gavin Scott)
Date: Thu, 24 Sep 2009 19:15:40 -0500
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> I remember working with CDC documentation that used 0 to label the msb
> (on the left).  That was the first time I had seen bits numbered that
> way and thought these guys must be pretty strange.  I still have not
> seen an explanation of why that convention would be adopted, but then
> the limeys all drive on the left too!  So go figure!

HP historically did this too with PA-RISC and earlier architectures.

In a big-endian world it can vaguely make sense as everything is read
from left to right with increasing addresses.

Of course can anyone use the words "left" and "right" without at
least considering that the whole thing is a bit mad really.

G.

Article: 143187
Subject: Lattice ispLever not starting
From: rickman <gnuarm@gmail.com>
Date: Thu, 24 Sep 2009 17:44:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have been using ispLever on this machine for over a year now.  I
just tried running a compile and I got an error message saying "Can't
read the ini file".  This comes up 7 times as I click the error box
away.  I restarted the tool and get this error before it comes up and
in fact, it never comes up.  I've rebooted the machine and still get
the error and the tool won't start.

Anyone know what causes this?  I assume it is a corrupt file, but all
it says is "ini file".

I guess I'll have to contact support tomorrow.  Geeze, I guess I
should have reupped the formal support plan.  I'd hate for them to
blow me off on this issue.

Rick

Article: 143188
Subject: Re: Shift left arithmetic?
From: rickman <gnuarm@gmail.com>
Date: Thu, 24 Sep 2009 17:49:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 24, 6:28=A0pm, Mike Treseler <mtrese...@gmail.com> wrote:
> rickman wrote:
> > It seems to be that they are doing the same thing...
>
> It depends on the type of arg:
>
> =A0 =A0 =A0-- Id: S.1
> =A0 =A0function shift_left =A0( =A0ARG: UNSIGNED; COUNT: NATURAL) return =
UNSIGNED;
> =A0 =A0 =A0 -- Result subtype: UNSIGNED (ARG'LENGTH-1 downto 0)
> =A0 =A0 =A0 -- Result: Performs a shift-left on an UNSIGNED vector COUNT =
times.
> =A0 =A0 =A0 -- =A0 =A0 =A0 =A0 The vacated positions are filled with Bit =
'0'.
> =A0 =A0 =A0 -- The COUNT leftmost bits are lost.
>
> =A0 =A0 =A0 -- Id: S.3
> =A0 =A0function shift_left =A0( =A0ARG: SIGNED; COUNT: NATURAL) return SI=
GNED;
> =A0 =A0 =A0 -- Result subtype: SIGNED (ARG'LENGTH-1 downto 0)
> =A0 =A0 =A0 -- Result: Performs a shift-left on a SIGNED vector COUNT tim=
es.
> =A0 =A0 =A0 -- =A0 =A0All bits of ARG, except ARG'LEFT, are shifted left =
COUNT times.
> =A0 =A0 =A0 -- =A0 =A0 =A0 =A0 The vacated positions are filled with Bit =
'0'.
> =A0 =A0 =A0 -- =A0 =A0 =A0 =A0 The COUNT leftmost bits, except ARG'LEFT, =
are lost.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ----------------

Why does your copy of this differ from mine?  You snipped my quote of
these functions, but they are very different.  Still, the fact remains
that it really doesn't matter.  If you shift the entire number and the
new value of the sign bit has changed, it was an overflow.  Even if
you don't shift the sign bit, it is still an overflow.

I checked the file I read and it is dated 1995.  I guess they
redefined the signed left shift at some point.  I wonder if that
caused anyone any trouble???


Rick

Article: 143189
Subject: Re: Shift left arithmetic?
From: rickman <gnuarm@gmail.com>
Date: Thu, 24 Sep 2009 17:52:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 24, 6:32=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> < I would suggest that FPGAs enforce rightmost bits being the lsb as
> < well as labeled with a 0. =A0That can be done in hardware, right? =A0;^=
)
>
> That is a strange comment. =A0FPGAs don't enforce anything. =A0One can
> number (or letter) the bits anyway one wants, the FPGA just supplying
> a collection of logic. =A0I don't know about VHDL but, as I said,
> verilog does not force one convention or the other.

You clearly didn't see the smiley...

Rick

Article: 143190
Subject: Re: Shift left arithmetic?
From: rickman <gnuarm@gmail.com>
Date: Thu, 24 Sep 2009 17:53:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 23, 5:47=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote:
> rickman wrote:
> > That is what I was taught was the way to perform an arithmetic left
> > shift, to fill the right positions with zero. =A0But this is also the
> > logical left shift operation. =A0I don't understand why a left shift
> > which fills the right most positions with the former lsb would be of
> > value. =A0I suppose it could just exist to fill the space in a chart,
> > but calling it an arithmetic left shift is a misnomer as arithmetic
> > would use the same shift as the logical left shift.
>
> But only because you suppose that the MSB is on the left side
> and the LSB on the right side.

Yeah, I guess it also depends on which side you consider to be the
right!

Rick

Article: 143191
Subject: Re: USB programmable Open Source Hardware
From: "Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com>
Date: Thu, 24 Sep 2009 23:33:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 22, 10:19=A0pm, nobody <cydrollin...@gmail.com> wrote:
> Looking for interest in an Open Source Hardware USB programmable FPGA,
> XC3S250E. I have been having some difficulty getting the right people
> exposed to this project. If you have any interest in this project
> would like to hear from you. It is headed into an Open Source Hardware
> agreement therefore their is no proprietary information about the
> design.
>
> Here is an image of the board.http://www.mediafire.com/imageview.php?quic=
kkey=3Dyhjjddznzmx&thumb=3D5
>
> Cy Drollinger
> Electronic Realization L.L.C.
> 313 W. Mendenhall #5
> Bozeman, MT 59715
> PH: 406-586-5502
> Email: c...@montana.net

Cy
does your company have a permananet web url?
or the product actually, i am writing september brain adding
the photo of you gadet too (with commentary)
would be nice to add link too - i will defenetly NOT link to mediafire
or something similar

Antti




Article: 143192
Subject: Re: Xilinx XST and counter synthesis problem
From: "nic_o_mat@msn.com" <nic_o_mat@msn.com>
Date: Fri, 25 Sep 2009 02:15:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 24, 5:39=A0pm, Matthieu Michon
<matthieu.d.u.m.m.y.mic...@gmail.com> wrote:
> On Thu, 24 Sep 2009 01:28:11 -0700 (PDT)
>
> "nic_o_...@msn.com" <nic_o_...@msn.com> wrote:
> > (...)
> > I always use an asynchronous reset description in my processes but the
> > actual reset signal is synchronized in another block.
> > I only posted the offending entity, the design is larer than this
> > single file.
>
> > I am no beginner and I did simulate my design before synthesizing it.
> > Simulation runs absolutely fine.
> > I have made further investigation, the SPI master generates the
> > correct number of clock cycles but only the 12 first bits are
> > transmitted, MOSI then goes high.
>
> > Nicolas
>
> In the case of a discrepancy in the behavior between simulation and execu=
tion, I would check the usuals :
> =A0- Synthesis and implementation transcript for anything even remotely s=
uspicious (while focusing manly on the logic optimization and timing).
> =A0- Reset signal synchronization is performed against the _correct_ cloc=
k net.
> =A0- RTL and physical (low-level) FPGA implementation of your design.
>
> While you may not have access to the JTAG interface of the FPGA (o/w I gu=
ess you'd already have used chipscope to probe the revelant nets), you can =
always throw a post p/r simulation, just to make sure that the toolchain di=
dn't caught its feet in the rug while implementing your design.
>
> Hope this helps.
>
> --
> Matthieu Michon

It seems that it was related to the "Map Slice Logic into Unused Block
RAMs" option that was enabled from a previous project I copied the tcl
script from.

Nicolas

Article: 143193
Subject: Re: Shift left arithmetic?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 25 Sep 2009 11:10:39 +0100
Links: << >>  << T >>  << A >>
On Thu, 24 Sep 2009 17:49:27 -0700 (PDT), rickman <gnuarm@gmail.com> wrote:

>On Sep 24, 6:28 pm, Mike Treseler <mtrese...@gmail.com> wrote:
>> rickman wrote:
>> > It seems to be that they are doing the same thing...
>>
>> It depends on the type of arg:
>>
>>      -- Id: S.1
>>    function shift_left  (  ARG: UNSIGNED; COUNT: NATURAL) return UNSIGNED;
>>       -- Result subtype: UNSIGNED (ARG'LENGTH-1 downto 0)
>>       -- Result: Performs a shift-left on an UNSIGNED vector COUNT times.
>>       --         The vacated positions are filled with Bit '0'.
>>       -- The COUNT leftmost bits are lost.
>>
>>       -- Id: S.3
>>    function shift_left  (  ARG: SIGNED; COUNT: NATURAL) return SIGNED;
>>       -- Result subtype: SIGNED (ARG'LENGTH-1 downto 0)
>>       -- Result: Performs a shift-left on a SIGNED vector COUNT times.
>>       --    All bits of ARG, except ARG'LEFT, are shifted left COUNT times.
>>       --         The vacated positions are filled with Bit '0'.
>>       --         The COUNT leftmost bits, except ARG'LEFT, are lost.
>>                                           ----------------
>
>Why does your copy of this differ from mine?  You snipped my quote of
>these functions, but they are very different.  Still, the fact remains
>that it really doesn't matter.  If you shift the entire number and the
>new value of the sign bit has changed, it was an overflow.  Even if
>you don't shift the sign bit, it is still an overflow.
>
>I checked the file I read and it is dated 1995.  I guess they
>redefined the signed left shift at some point.  I wonder if that
>caused anyone any trouble???

Or was it a documentation error of the cut/paste variety, later corrected?
I would think this more likely than an actual change in behaviour.

If you look at the associated package body (usually a second file) the source
code should make it clear what the function really does.

- Brian


Article: 143194
Subject: Re: Virtex 4 configruation frame internal details
From: Symon <symon_brewer@hotmail.com>
Date: Fri, 25 Sep 2009 11:35:00 +0100
Links: << >>  << T >>  << A >>
Frank Buss wrote:
> Antti.Lukats@googlemail.com wrote:
> 
>> hm if that is the easy way, what is the hard way?
> 
> The hard way would be to use two different VHDL files and compare the
> bitstreams :-)
> 
I think that's the medium difficulty way, Frank. The hard way is to etch 
off the packaging and metal/silicon layers with HF while looking at the 
die under an electron microscope to reverse engineer the silicon. While 
standing on one leg.

Cheers, Syms.

Article: 143195
Subject: Re: Lattice ispLever not starting
From: Charles Gardiner <invalid@invalid.invalid>
Date: Fri, 25 Sep 2009 12:46:05 +0200
Links: << >>  << T >>  << A >>
Normally ispLever installs the *.ini files to c:\lsc_env. You can change
this by setting the variable LSC_INI_PATH to something like
%USERPROFILE%\lsc_env

If yours has become screwed up somehow, you can write your own based on
the one below (from German windows Server 2003):
Store it under lsc_7_2.ini in whichever lsc_env directory you decide to
use original or one pointed to by LSC_INI_PATH).

Sorry, but I can't restrain myself on my favorite rant here. The big
problem is the cluelessness of so many windows SW developers who still
have not realised that computers in the 21th century are largely
multi-user or at least that the SW should support that model. Putting
one config file for everbody in a privately invented directory should
have died out around 1990. It would be a great help to the user if these
developers took the time to look at the windows API and read the section
Win32 and Com Development -> Administration and Management
                          -> Policies and Profiles
(Now, I'm feeling better)


[paths]
Bin=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\bin
Config=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\config
Examples=C:\Programme\Lattice\ispTOOLS7_2\examples
FPGAPath=C:\Programme\Lattice\ispTOOLS7_2\ispfpga
FPGABinPath=C:\Programme\Lattice\ispTOOLS7_2\ispfpga\bin\nt
INI=C:\lsc_env
License=C:\Programme\Lattice\ispTOOLS7_2\license
Root=C:\Programme\Lattice\ispTOOLS7_2\ispcpld
ispVM=C:\Programme\Lattice\ispTOOLS7_2\ispvmsystem
SpectrumPath="C:\isptools\spectrum"
PrecisionPath=""
ModelsimPath=""
SynplifyPath=C:\Programme\Lattice\ispTOOLS7_2\synpbase
MachPath=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\bin
AppNotes=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\bin
PDSPath=C:\Programme\Lattice\ispTOOLS7_2\ispcomp
Tutorial=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\tutorial
Manuals=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\manuals
DSPPATH=C:\Programme\Lattice\ispTOOLS7_2\ispLeverDSP
TclPath=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\tcltk\bin
ActiveHDLPath=C:\Programme\Lattice\ispTOOLS7_2\active-hdl\bin

[Strings]
ProductName=ispLEVER
ProductPrefix=SYN
ProductTitle=ispLEVER
ProductVersion=7.2.00.07
ProductType=7.2.00.41.49.08_LS_HDL_BASE_PC_N
ProgramFolder=Lattice Semiconductor 7.2

[CPLD]

[FPGA]
LSCC_DEV_PATH=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\data
LSCC_RDD_PATH=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\data
LSCC_LIB_PATH=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\data
LSCC_LCI_PATH=C:\Programme\Lattice\ispTOOLS7_2\ispcpld\config
LSDB_COMPRESSED = "1"


[Packages]
LatticeGNUCompiler=C:\Programme\Lattice\ispTOOLS7_2\micosystem
LatticeMico32System=C:\Programme\Lattice\ispTOOLS7_2\micosystem
Synplify=C:\Programme\Lattice\ispTOOLS7_2\synpbase
Spectrum="C:\isptools\spectrum"
Precision=""
ModelSim=""
ispVMSystem=C:\Programme\Lattice\ispTOOLS7_2\ispvmsystem
HDLExplorer=C:\Programme\Lattice\ispTOOLS7_2\hdle\win32
EPICPATH=C:\Programme\Lattice\ispTOOLS7_2\ispfpga\bin\nt
LM32PATH="C:\isptools\micosystem"
ActiveHDL=C:\Programme\Lattice\ispTOOLS7_2\active-hdl\bin
[Symbols]
DeviceFamily=ORCALDB5_JED_T_VHD
ProjectType=Device
ToolMenu=ORCATLM32REVEAL
CurrentProject=C:\Dokumente und Einstellungen\Administrator\Eigene
Dateien\Lattice\pcie_easi.syn
EntryType=Pure VHDL
FlowType=NORMAL
Simulator=ActiveHDL
RevealInsert=false
UseDefinedSymbols=c:\dokumente und einstellungen\administrator\eigene
dateien\lattice\pcie_easi.ini


Article: 143196
Subject: Weird DDR Addressing problem
From: George <bishopg12@gmail.com>
Date: Fri, 25 Sep 2009 05:42:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'm currently debugging a design with a Xilinx FX20 FPGA and 2
MT46V16M16BG-6 DDR chips.  When writing a series of test patterns to
the memory and reading it back I get some strange results:

Writing a series of test patterns at byte addresses 0,4,8...
Testing Tap 27,Regfile 50000000
Writing DEADBEEF at 00000000
Writing 11111111 at 00000004
Writing 22222222 at 00000008
Writing 33333333 at 0000000C
Writing 44444444 at 00000010
Writing 55555555 at 00000014
Writing 66666666 at 00000018
Writing 77777777 at 0000001C
Wr:DEADBEEF,
11111111,22222222,33333333,44444444,55555555,66666666,77777777
Rd:DEADBEEF,11111111,DEADBEEF,11111111,DEADBEEF,11111111,DEADBEEF,
11111111


You can see that 0x0 and 0x4 write and read correctly, but the
subsequent writes to 0x8, 0xC, 0x10, 0x14, 0x18, 0x1C are all
duplicates of the first set.

If I change the writes to multiples of 8 (0x0, 0x8, 0x10, 0x18, 0x20,
0x28, 0x30, 0x38) I get the following output:

Testing Tap 27,Regfile 50000000
Writing DEADBEEF at 00000000
Writing 11111111 at 00000008
Writing 22222222 at 00000010
Writing 33333333 at 00000018
Writing 44444444 at 00000020
Writing 55555555 at 00000028
Writing 66666666 at 00000030
Writing 77777777 at 00000038
Wr:DEADBEEF,
11111111,22222222,33333333,44444444,55555555,66666666,77777777
Rd:DEADBEEF,DEADBEEF,DEADBEEF,DEADBEEF,
44444444,44444444,44444444,44444444

Step size of 16:

Testing Tap 27,Regfile 50000000
Writing DEADBEEF at 00000000
Writing 11111111 at 00000010
Writing 22222222 at 00000020
Writing 33333333 at 00000030
Writing 44444444 at 00000040
Writing 55555555 at 00000050
Writing 66666666 at 00000060
Writing 77777777 at 00000070
Wr:DEADBEEF,
11111111,22222222,33333333,44444444,55555555,66666666,77777777
Rd:DEADBEEF,DEADBEEF,
22222222,22222222,44444444,44444444,66666666,66666666

And if I again change the multiples to 32, everything works.

Testing Tap 27,Regfile 50000000
Writing DEADBEEF at 00000000
Writing 11111111 at 00000020
Writing 22222222 at 00000040
Writing 33333333 at 00000060
Writing 44444444 at 00000080
Writing 55555555 at 000000A0
Writing 66666666 at 000000C0
Writing 77777777 at 000000E0
Wr:DEADBEEF,
11111111,22222222,33333333,44444444,55555555,66666666,77777777
Rd:DEADBEEF,
11111111,22222222,33333333,44444444,55555555,66666666,77777777
Read and writes match

I thought maybe it was a trace or two on the board that might be bad
(tied to another, not the correct length), but I exchanged address
lines with higher ones and got the same results.  I.e.

        Original
    FPGA Address        DDR Address
    0            0
    1            1
    2            2


        Exchanged
    0            0
    1            3
    2            4

Any insight would be greatly appreciated.

Thanks!

Article: 143197
Subject: Re: Weird DDR Addressing problem
From: gabor <gabor@alacron.com>
Date: Fri, 25 Sep 2009 06:02:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 25, 8:42=A0am, George <bishop...@gmail.com> wrote:
> I'm currently debugging a design with a Xilinx FX20 FPGA and 2
> MT46V16M16BG-6 DDR chips. =A0When writing a series of test patterns to
> the memory and reading it back I get some strange results:
>
> Writing a series of test patterns at byte addresses 0,4,8...
> Testing Tap 27,Regfile 50000000
> Writing DEADBEEF at 00000000
> Writing 11111111 at 00000004
> Writing 22222222 at 00000008
> Writing 33333333 at 0000000C
> Writing 44444444 at 00000010
> Writing 55555555 at 00000014
> Writing 66666666 at 00000018
> Writing 77777777 at 0000001C
> Wr:DEADBEEF,
> 11111111,22222222,33333333,44444444,55555555,66666666,77777777
> Rd:DEADBEEF,11111111,DEADBEEF,11111111,DEADBEEF,11111111,DEADBEEF,
> 11111111
>
> You can see that 0x0 and 0x4 write and read correctly, but the
> subsequent writes to 0x8, 0xC, 0x10, 0x14, 0x18, 0x1C are all
> duplicates of the first set.
>
> If I change the writes to multiples of 8 (0x0, 0x8, 0x10, 0x18, 0x20,
> 0x28, 0x30, 0x38) I get the following output:
>
> Testing Tap 27,Regfile 50000000
> Writing DEADBEEF at 00000000
> Writing 11111111 at 00000008
> Writing 22222222 at 00000010
> Writing 33333333 at 00000018
> Writing 44444444 at 00000020
> Writing 55555555 at 00000028
> Writing 66666666 at 00000030
> Writing 77777777 at 00000038
> Wr:DEADBEEF,
> 11111111,22222222,33333333,44444444,55555555,66666666,77777777
> Rd:DEADBEEF,DEADBEEF,DEADBEEF,DEADBEEF,
> 44444444,44444444,44444444,44444444
>
> Step size of 16:
>
> Testing Tap 27,Regfile 50000000
> Writing DEADBEEF at 00000000
> Writing 11111111 at 00000010
> Writing 22222222 at 00000020
> Writing 33333333 at 00000030
> Writing 44444444 at 00000040
> Writing 55555555 at 00000050
> Writing 66666666 at 00000060
> Writing 77777777 at 00000070
> Wr:DEADBEEF,
> 11111111,22222222,33333333,44444444,55555555,66666666,77777777
> Rd:DEADBEEF,DEADBEEF,
> 22222222,22222222,44444444,44444444,66666666,66666666
>
> And if I again change the multiples to 32, everything works.
>
> Testing Tap 27,Regfile 50000000
> Writing DEADBEEF at 00000000
> Writing 11111111 at 00000020
> Writing 22222222 at 00000040
> Writing 33333333 at 00000060
> Writing 44444444 at 00000080
> Writing 55555555 at 000000A0
> Writing 66666666 at 000000C0
> Writing 77777777 at 000000E0
> Wr:DEADBEEF,
> 11111111,22222222,33333333,44444444,55555555,66666666,77777777
> Rd:DEADBEEF,
> 11111111,22222222,33333333,44444444,55555555,66666666,77777777
> Read and writes match
>
> I thought maybe it was a trace or two on the board that might be bad
> (tied to another, not the correct length), but I exchanged address
> lines with higher ones and got the same results. =A0I.e.
>
> =A0 =A0 =A0 =A0 Original
> =A0 =A0 FPGA Address =A0 =A0 =A0 =A0DDR Address
> =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A00
> =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A01
> =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A02
>
> =A0 =A0 =A0 =A0 Exchanged
> =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A00
> =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A03
> =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A04
>
> Any insight would be greatly appreciated.
>
> Thanks!

With 2 16-bit chips, a "word" internal to the FPGA would actually
be 64 bits, not 32.  So in the first case it looks like you read
the same "word" over and over probably for a full burst.  You didn't
say what burst size you use or even which controller (MIG? MPMC?)
In any case it is possible that the burst size of the device is
not set properly during start-up, causing a full burst to be only
a single "word", while the controller expects it to be 4 words.
This could cause the symptoms you see.  By the way you can't
re-arrange the address lines unless you also move the mode
register bits around to match the lines.  The address lines are
effectively the data bits for mode register loads.  I would
check to see what you have programmed in the mode register
to make sure it matches your expectations.

Regards,
Gabor

Article: 143198
Subject: Re: Weird DDR Addressing problem
From: George <bishopg12@gmail.com>
Date: Fri, 25 Sep 2009 06:39:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
I'm using the mpmc controller.  I thought the burst size of the ddr
was 4 words, and I don't see any way to change this in the mpmc
interface.

Thanks,
George

Article: 143199
Subject: Re: Weird DDR Addressing problem
From: George <bishopg12@gmail.com>
Date: Fri, 25 Sep 2009 06:49:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 25, 9:39=A0am, George <bishop...@gmail.com> wrote:
> I'm using the mpmc controller. =A0I thought the burst size of the ddr
> was 4 words, and I don't see any way to change this in the mpmc
> interface.
>
> Thanks,
> George

Sorry, I retract that previous statement.  I see in the datasheet that
the burst length can be programmed to 2,4,or 8.



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