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 136250

Article: 136250
Subject: Re: Setting FSM encoding in VHDL or in UCF for Xilinx
From: Dale <dale.prather@gmail.com>
Date: Fri, 7 Nov 2008 11:23:46 -0800 (PST)
Links: << >>  << T >>  << A >>
KJ, thanks for your input.  The issue came up when we started getting
a glitch in one of our state machine outputs.  It was a FSM we've been
carrying from project to project for years.  It has always worked and
then stopped.  Ultimately, the glitching was a result of ISE's auto
setting doing something different from one version of ISE to the
next.  It was implementing the FSM in such a way that we were getting
the glitch.  I set the fsm encoding to "none" and the glitching went
away.  So,"trusting the synthesizer" is not always a good idea as I
found the hard way.  Especially in an aerospace project that needs to
be DO-254 certified.  I necessarily need to know what the synthesizer
is doing.  Had changing to a recent ISE version not caused the
glitching, I would not be as concerned about it.

I'm all about making portable code, but making 100% portable code is
nearly impossible.  If I don't use the nonportable attribute in the
vhdl file then I still have to use the sysnthesizers nonportable GUI
to set the encoding algorithm.  Also, using the GUI method I cannot
set multiple FSMs to different encoding algorithms.  The GUI is all or
none.  If you know of a method that is 100% portable, I would be
interested in that.

Writing the FSM a certain way won't guarantee how the synthesizer
implements it, that I know of.  As stated in the 10.1 manual, XST
extracts FSMs and encodes them according to the setting.

Dale

Article: 136251
Subject: Re: Tilera multicore replaces FPGA?
From: Benjamin Couillard <benjamin.couillard@gmail.com>
Date: Fri, 7 Nov 2008 11:26:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On 7 nov, 14:00, Leon <leon...@btinternet.com> wrote:
> On 7 Nov, 18:00, Benjamin Couillard <benjamin.couill...@gmail.com>
> wrote:
>
>
>
> > On 7 nov, 11:47, Leon <leon...@btinternet.com> wrote:
>
> > > On 7 Nov, 16:11, Benjamin Couillard <benjamin.couill...@gmail.com>
> > > wrote:
>
> > > > On 7 nov, 05:25, mentari <Stephan...@gmail.com> wrote:
>
> > > > > What are your views onhttp://scratchpad.wikia.com/wiki/TileraMult=
icore
> > > > > as a replacement for FPGA's ?
>
> > > > >http://www.tilera.com/solutions/digital_baseband.php
>
> > > > > The current architecture for base stations fall short of deliveri=
ng
> > > > > the performance, the low latency and the flexibility customers ne=
ed.
> > > > > To meet the requirements, wireless equipment providers design com=
plex
> > > > > systems with FPGA, ASIC, DSP and processors with each component
> > > > > requiring special tools in a customized development environment. =
This
> > > > > leads to a long development cycle, sometimes years, before
> > > > > applications can be productized. Changes in standards also impact
> > > > > providers because such systems are inflexible-upgrades can be a s=
low
> > > > > and expensive process.
>
> > > > > What providers seek is an uncomplicated, well-designed, architect=
ure
> > > > > that yields good performance. Tilera's processors provide a low
> > > > > latency single solution that integrates many functions seamlessly=
 in a
> > > > > single processor and uses C/C++ to program their applications wit=
h
> > > > > industry standard tools. The familiar tools enable customers to
> > > > > preserve their software investments, replace a number of disparat=
e
> > > > > programming methodologies with one standard programming environme=
nt,
> > > > > and gain the flexibility they need to support evolving protocols =
and
> > > > > ever-increasing demands for service
>
> > > > It seems to be similar to XMOS devices. I suppose that it could
> > > > replace FPGAs in some applications. However, it's still a much coar=
ser
> > > > architecture than an FPGA. =A0There's still only 64 processing unit=
s,
> > > > while a Virtex-5 can have about 20 000 slices and a couple of PPC
> > > > processors. In the end, I think that since FPGAs are much more
> > > > flexible, they have the upper hand. Plus with tools like system
> > > > generator, AccelDSP and Simulink, low-level HDL coding can be skipp=
ed,
> > > > and the engineer can focus more on applications and less on the "bi=
t-
> > > > level" of things.
>
> > > > Plus I suppose that with a high-capacity FPGA, one could emulate a
> > > > Tilera-like device with 64 processing units. Maybe the future's the=
re,
> > > > take the Tilera (or Xmos) concept and implement it in a FPGA.
>
> > > > My 2 cents
>
> > > They will cost more, be much harder to use, use a lot more power and
> > > won't be any faster.
>
> > > Leon
>
> > THe point is not that it will be faster, is that it'll be much more
> > versatile since you won't be stuck with a fixed architecture
>
> You won't have 64k per core, and what about stuff like 100 MHz I/Os,
> hardware threads switching in one cycle, and 3.2 Gb/s full duplex
> links between cores?
>
> Leon

You raise some good points.
But, I was just making the point that you could implement some sort of
"xmos-like" architecture in a big FPGA. While you wouldn't have 64k
per core , you would certainly be able to have 3.2 Gb/s full duplex
(32 bits @ 100 MHz).

But anyay, I think that FPGAs are there to stay and they have a big
future in front of them. There might be some applications where
they'll be replaced by faster, cheaper technologies, but the reverse
is also true.


Article: 136252
Subject: Re: Tilera multicore replaces FPGA?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Fri, 07 Nov 2008 20:29:28 +0100
Links: << >>  << T >>  << A >>
mentari <StephanusR@gmail.com> writes:

> What are your views on http://scratchpad.wikia.com/wiki/TileraMulticore

Are they cache coherent? If not what types of libraries do they
provide, e.g. is MPI supported? What about debuggers for the
architecture?

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 136253
Subject: Re: Tilera multicore replaces FPGA?
From: Leon <leon355@btinternet.com>
Date: Fri, 7 Nov 2008 11:43:26 -0800 (PST)
Links: << >>  << T >>  << A >>
On 7 Nov, 19:26, Benjamin Couillard <benjamin.couill...@gmail.com>
wrote:
> On 7 nov, 14:00, Leon <leon...@btinternet.com> wrote:
>
>
>
> > On 7 Nov, 18:00, Benjamin Couillard <benjamin.couill...@gmail.com>
> > wrote:
>
> > > On 7 nov, 11:47, Leon <leon...@btinternet.com> wrote:
>
> > > > On 7 Nov, 16:11, Benjamin Couillard <benjamin.couill...@gmail.com>
> > > > wrote:
>
> > > > > On 7 nov, 05:25, mentari <Stephan...@gmail.com> wrote:
>
> > > > > > What are your views onhttp://scratchpad.wikia.com/wiki/TileraMu=
lticore
> > > > > > as a replacement for FPGA's ?
>
> > > > > >http://www.tilera.com/solutions/digital_baseband.php
>
> > > > > > The current architecture for base stations fall short of delive=
ring
> > > > > > the performance, the low latency and the flexibility customers =
need.
> > > > > > To meet the requirements, wireless equipment providers design c=
omplex
> > > > > > systems with FPGA, ASIC, DSP and processors with each component
> > > > > > requiring special tools in a customized development environment=
. This
> > > > > > leads to a long development cycle, sometimes years, before
> > > > > > applications can be productized. Changes in standards also impa=
ct
> > > > > > providers because such systems are inflexible-upgrades can be a=
 slow
> > > > > > and expensive process.
>
> > > > > > What providers seek is an uncomplicated, well-designed, archite=
cture
> > > > > > that yields good performance. Tilera's processors provide a low
> > > > > > latency single solution that integrates many functions seamless=
ly in a
> > > > > > single processor and uses C/C++ to program their applications w=
ith
> > > > > > industry standard tools. The familiar tools enable customers to
> > > > > > preserve their software investments, replace a number of dispar=
ate
> > > > > > programming methodologies with one standard programming environ=
ment,
> > > > > > and gain the flexibility they need to support evolving protocol=
s and
> > > > > > ever-increasing demands for service
>
> > > > > It seems to be similar to XMOS devices. I suppose that it could
> > > > > replace FPGAs in some applications. However, it's still a much co=
arser
> > > > > architecture than an FPGA. =A0There's still only 64 processing un=
its,
> > > > > while a Virtex-5 can have about 20 000 slices and a couple of PPC
> > > > > processors. In the end, I think that since FPGAs are much more
> > > > > flexible, they have the upper hand. Plus with tools like system
> > > > > generator, AccelDSP and Simulink, low-level HDL coding can be ski=
pped,
> > > > > and the engineer can focus more on applications and less on the "=
bit-
> > > > > level" of things.
>
> > > > > Plus I suppose that with a high-capacity FPGA, one could emulate =
a
> > > > > Tilera-like device with 64 processing units. Maybe the future's t=
here,
> > > > > take the Tilera (or Xmos) concept and implement it in a FPGA.
>
> > > > > My 2 cents
>
> > > > They will cost more, be much harder to use, use a lot more power an=
d
> > > > won't be any faster.
>
> > > > Leon
>
> > > THe point is not that it will be faster, is that it'll be much more
> > > versatile since you won't be stuck with a fixed architecture
>
> > You won't have 64k per core, and what about stuff like 100 MHz I/Os,
> > hardware threads switching in one cycle, and 3.2 Gb/s full duplex
> > links between cores?
>
> > Leon
>
> You raise some good points.
> But, I was just making the point that you could implement some sort of
> "xmos-like" architecture in a big FPGA. While you wouldn't have 64k
> per core , you would certainly be able to have 3.2 Gb/s full duplex
> (32 bits @ 100 MHz).
>
> But anyay, I think that FPGAs are there to stay and they have a big
> future in front of them. There might be some applications where
> they'll be replaced by faster, cheaper technologies, but the reverse
> is also true.

They won't replace them completely, of course, but there will be many
applications where the ease of development (a C-like language with
compilation  and testing in a few seconds) and low cost will see them
being used in place of FPGAs, and in conjunction with them. One
application I've heard of uses a CPLD as an XLink interface to an XMOS
chip, and I'm thinking of using an FPGA between an RF ADC and the XMOS
chip for a software defined radio.

Leon

Article: 136254
Subject: Re: Setting FSM encoding in VHDL or in UCF for Xilinx
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 7 Nov 2008 12:36:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 7, 2:23 pm, Dale <dale.prat...@gmail.com> wrote:
> KJ, thanks for your input.  The issue came up when we started getting
> a glitch in one of our state machine outputs.

Then the design error would appear to be that this state machine
output is not the output of a flip flop as it should be since it is
apparently required to be glitchless.  One way to fix it would be to
find the logic for that code and get it inside of a clocked process.

> It was a FSM we've been
> carrying from project to project for years.  It has always worked and
> then stopped.

The state machine stopped because of a glitch on an output???  That
doesn't make much sense on a couple fronts:
- State machine outputs do not affect the operation of the state
machine.  Maybe what you mean is that this glitch caused some other
logic to fail.
- A glitch that causes a functional problem is indicative of not
following a synchronous design process which is always bad news in an
FPGA...even if something that has 'worked for years' (but in different
designs).

> Ultimately, the glitching was a result of ISE's auto
> setting doing something different from one version of ISE to the
> next.  It was implementing the FSM in such a way that we were getting
> the glitch.

What you should be investigating is why the glitch caused any sort of
failure.  Synchronous designs work well in FPGAs, non-synchronous ones
will (with near certainty) eventually fail under some conditions.
Until you get rid of the logic that is failing due to the glitch your
design is likely to be fragile.

> I set the fsm encoding to "none" and the glitching went
> away.  So,"trusting the synthesizer" is not always a good idea as I
> found the hard way.  Especially in an aerospace project that needs to
> be DO-254 certified.  I necessarily need to know what the synthesizer
> is doing.  Had changing to a recent ISE version not caused the
> glitching, I would not be as concerned about it.
>

Yeah, but now that you are concerned you really need to get to the
true root cause.  Fiddling with tool settings to make it appear to
work is setting yourself up for headaches down the road because you
haven't really identified the root cause of the problem, you've only
identified a band-aid that appears to fix the problem but does not
address the root cause because that has not yet been identified.

> I'm all about making portable code, but making 100% portable code is
> nearly impossible.  If I don't use the nonportable attribute in the
> vhdl file then I still have to use the sysnthesizers nonportable GUI
> to set the encoding algorithm.  Also, using the GUI method I cannot
> set multiple FSMs to different encoding algorithms.  The GUI is all or
> none.  If you know of a method that is 100% portable, I would be
> interested in that.
>
> Writing the FSM a certain way won't guarantee how the synthesizer
> implements it, that I know of.  As stated in the 10.1 manual, XST
> extracts FSMs and encodes them according to the setting.
>

Like I mentioned above, I think you really need to get to the bottom
of why a glitch on a particular signal causes a failure in the first
place.  However, to address this particular point of how to write code
that guarantees a particular encoding, here is the following snippet.
Basically, instead of defining an enumerated type, you define a
std_logic_vector of the appropriate width and then define an array
constant with the names you'd like to associate with those encodings.

type StateStd_Typ is array(State_Typ) of std_logic_vector(1 downto
0); ,
constant State2Std_c : StateStd_Typ :=
  (IDLE => "00",
   FETCH => "01",
  DECODE => "10",
  EXECUTE => "11);

Good luck.

Kevin Jennings

Article: 136255
Subject: Re: led programming
From: Gabor <gabor@alacron.com>
Date: Fri, 7 Nov 2008 12:58:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 7, 10:38=A0am, uraniumore...@gmail.com wrote:
> Hello all,
>
> I am having some issues with this piece of code, which is supposed to
> work correctly with the spartan 3 leds.
> I am trying to display a 16 bit count to the led display; however, the
> value on the leddisplay produces duplicate values across all 4 leds.
> Is there something I am doing wrong with the code ?
>
> Please help,
> Uchenna Anyanwu
>
> always @ ( posedge done or posedge reset)
> begin
> if(reset)
> leddisp <=3D 0;
> else
> leddisp[15:0] <=3D numcounter1 - numcounter2;
> go =3D 1;
> end
>
> always @ (posedge go)
> begin
> if(go)
> difcount1=3D{leddisp[3], leddisp[2], leddisp[1],leddisp[0]};
> end
>
> always @ (posedge go)
> begin
> if(go)
> difcount2=3D{leddisp[7], leddisp[6], leddisp[5], leddisp[4]};
> end
>
> always @ (posedge go)
> begin
> if(go)
> difcount3=3D{leddisp[11], leddisp[10], leddisp[9], leddisp[8]};
> end
>
> always @ (posedge go)
> begin
> if (go)
> difcount4=3D{leddisp[15], leddisp[14], leddisp[13], leddisp[12]};
> end
>
> led u3 (difcount1,s0, s1, s2, s3, s4, s5, s6);
> led u4 (difcount2,s7, s8, s9, s10, s11, s12, s13);
> led u5 (difcount3,s14, s15, s16, s17, s18, s19,s20);
> led u6 (difcount4,s21, s22, s23, s24, s25, s26, s27);
>
> LED_MUX u7 (/*clkbuf*/ clk_50Mhz, reset, {s6, s5, s4, s3, s2, s1, s0},
> {s13,s12,s11,s10,s9,s8,s7}, {s20,s19,s18,s17,s16,s15,s14},
> {s27,s26,s25,s24,s23,s22,s21}, LEDOUT, LEDSEL );
>
> endmodule
>
> module led(number, s0, s1, s2, s3, s4, s5, s6);
> output s0, s1, s2, s3, s4, s5, s6;
> input [3:0] number;
> reg s0, s1, s2, s3, s4, s5, s6;
> always @ (number)
> begin // BCD to 7-segment decoding
> case (number) // s0 ? s6 are active low
> 4'b0000: begin s0=3D0; s1=3D0; s2=3D0; s3=3D1; s4=3D0; s5=3D0; s6=3D0; en=
d
> 4'b0001: begin s0=3D1; s1=3D0; s2=3D1; s3=3D1; s4=3D0; s5=3D1; s6=3D1; en=
d
> 4'b0010: begin s0=3D0; s1=3D1; s2=3D0; s3=3D0; s4=3D0; s5=3D1; s6=3D0; en=
d
> 4'b0011: begin s0=3D0; s1=3D0; s2=3D1; s3=3D0; s4=3D0; s5=3D1; s6=3D0; en=
d
> 4'b0100: begin s0=3D1; s1=3D0; s2=3D1; s3=3D0; s4=3D0; s5=3D0; s6=3D1; en=
d
> 4'b0101: begin s0=3D0; s1=3D0; s2=3D1; s3=3D0; s4=3D1; s5=3D0; s6=3D0; en=
d
> 4'b0110: begin s0=3D0; s1=3D0; s2=3D0; s3=3D0; s4=3D1; s5=3D0; s6=3D0; en=
d
> 4'b0111: begin s0=3D1; s1=3D0; s2=3D1; s3=3D1; s4=3D0; s5=3D1; s6=3D0; en=
d
> 4'b1000: begin s0=3D0; s1=3D0; s2=3D0; s3=3D0; s4=3D0; s5=3D0; s6=3D0; en=
d
> 4'b1001: begin s0=3D0; s1=3D0; s2=3D1; s3=3D0; s4=3D0; s5=3D0; s6=3D0; en=
d
> default: begin s0=3D1; s1=3D1; s2=3D1; s3=3D1; s4=3D1; s5=3D1; s6=3D1; en=
d
> endcase
> end
> endmodule // end led
>
> module LED_MUX (clk, rst, LED0, LED1, LED2, LED3, LEDOUT, LEDSEL);
> input clk, rst;
> input [7:0] LED0, LED1, LED2, LED3;
> output[3:0] LEDSEL;
> reg [3:0] LEDSEL;
> output[6:0] LEDOUT;
> reg [6:0] LEDOUT;
> reg [1:0] index;
> always @(posedge clk)
> begin
> if(rst)
> index =3D 0;
> else
> index =3D index + 1;
> end
> always @(index or LED0 or LED1 or LED2 or LED3)
> begin
> case(index)
> 0: begin
> LEDSEL =3D 4'b1110;
> LEDOUT =3D LED0;
> end
> 1: begin
> LEDSEL =3D 4'b1101;
> LEDOUT =3D LED1;
> end
> 2: begin
> LEDSEL =3D 4'b1011;
> LEDOUT =3D LED2;
> end
> 3: begin
> LEDSEL =3D 4'b0111;
> LEDOUT =3D LED3;
> end
> default: begin
> LEDSEL =3D 0; LEDOUT =3D 0;
> end
> endcase
> end
> endmodule

Are you sure that LEDSEL is active low?  If it connects directly to
the LED
anodes I would guess it should be active high.

Article: 136256
Subject: Re: Tilera multicore replaces FPGA?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 08 Nov 2008 10:09:01 +1300
Links: << >>  << T >>  << A >>
Benjamin Couillard wrote:
> You raise some good points.
> But, I was just making the point that you could implement some sort of
> "xmos-like" architecture in a big FPGA. While you wouldn't have 64k
> per core , you would certainly be able to have 3.2 Gb/s full duplex
> (32 bits @ 100 MHz).
> 
> But anyay, I think that FPGAs are there to stay and they have a big
> future in front of them. There might be some applications where
> they'll be replaced by faster, cheaper technologies, but the reverse
> is also true.


True, but FPGA markets will suffer from short lifetimes. As soon
as the use gets sufficently stable, and the volumes ramp, someone
comes along with a Silicon solution that displaces the FPGA

Here is a good example = Freescale have just released a 6 core DSP
www.freescale.com%2F&esheet=5822117&lan=en_US&anchor=www.freescale.com&index=1

This targets applications that used DSP+FPGA before.

Of course, the MSC8156 AND a FPGA will be more powerful again...

-jg



Article: 136257
Subject: Re: Tilera multicore replaces FPGA?
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 7 Nov 2008 13:09:58 -0800 (PST)
Links: << >>  << T >>  << A >>
Mentari -

Please do us the favor of identifying yourself as an interested party
in Tilera or tell us why you're posting here in comp.arch.fpga with
absolutely no apparent history in this newsgroup.

It's often okay for an occasional post from a company with a new,
compelling architecture to stir interest on a very related newsgroup,
but not so much through pretext.  Participants in this newsgroup have
had tremendous interactions in the past with professionals from the
compainies involved in products for the markets we work in.

Personally, I don't like people passing themselves off as "random
interested party" when they're a pump & dump investor or a marketing
person trying to "sneak in" some interest as if it's a grass roots
effort.

If you have no affiliation with the company or its products, you are
certainly an unusual participant in this group with complete, well
thought-out communication down to the detail of your diction to the
extent that engineering doesn't appear to your primary interest.
Engineers can communicate well but we're often more interested in the
meat and meaning of the conversation rather than well considered
prose.  You look like marketing.

If you really are an interested engineer, more power to ya.  But I
don't like looking at threads with strong suspicion.

- John_H

Article: 136258
Subject: Re: Xilinx Floorplaner X,y Coordinates
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 7 Nov 2008 13:20:18 -0800 (PST)
Links: << >>  << T >>  << A >>
Felix Stocker wrote:
> Hi
>
> I have a stupid question. I try to locate where my units of the
> floorplaner are then actually on the physical chip!
> So I am wondering there where the physical chip has its mark (a point)
> I assume that is Slice X0Y0 is that right? If that is the case then the
> Floorplaner would be quite confusing as it has X0Y79 in the upper left
> corner.
>
> Thanks for clarification ;)
> Silly Boy

Look at FPGA Editor for the coordinates.  Different silicon from
different vendors can have the origin in a different location
depending on whether the numbering basis is 1) a printed page order
(please note at least 3 differences in read direction for different
languages - I'm thinking english, hebrew, and traditional chinese), 2)
a common graphical system based on cartesian coordinates, and 3)
whether the silicon is a flip chip such that the orientation to the
user (looking at the package top) does not represent the silicon's
"top" side.

I think the X0Y0 is typically the lower left in Xilinx devices
corresponding to a catesian coordinate system used in most
mathematics.

- John_H

Article: 136259
Subject: Re: Setting FSM encoding in VHDL or in UCF for Xilinx
From: Dale <dale.prather@gmail.com>
Date: Fri, 7 Nov 2008 14:17:52 -0800 (PST)
Links: << >>  << T >>  << A >>
Kevin, you bring up some interesting points.  I've pasted the state
machine in question.  It's a very simple FSM.  Let me explain the
glitching a little better.  Maybe my sentence was confusing when I
said "it stopped".  I meant to say it stopped working as desired (the
glitch).  The output of the FSM was glitching.  Specifically signals
U_nWR1, U_nRD1 and U_ADS (seen below).  These are control signals for
a UART.  When those signals glitch the UART's timing constraints
aren't met and the communication with the UART fails.  Do you see a
problem with how this state machine is coded?  Thanks again.

process (H1)
begin
if H1'event and H1 = '0' then
	if nReset_B='0' then
		Sreg0 <= "001"; -- S0
		Sreg1 <= "01"; -- S0
	else

	case Sreg0 is
		when "001" => -- S0
			if nPage3_244='0' then
				Sreg0 <= "000"; -- S1
			else
				Sreg0 <= "001"; -- S0
			end if;
		when "000" => --S1
			Sreg0 <= "010"; --S2
		when "010" => -- S2
			Sreg0 <= "100";  --S3
		when "100" =>  --S3
			Sreg0 <= "111"; --S4
		when "111" =>  --S4
			if nPage3_244='1' then
				Sreg0 <= "001"; -- S0
			else
				Sreg0 <= "111"; -- S4
			end if;
		when others =>   -- trap state
			Sreg0 <= "001"; -- S0
	end case;

	case Sreg1 is
		when "01" => -- S0
			if nPage3_244='0' then
				Sreg1 <= "10"; -- S1
			else
				Sreg1 <= "01"; -- S0
			end if;
		when "10" => --S1
			Sreg1 <= "11"; --S2
		when "11" =>  --S2
			if nPage3_244='1' then
				Sreg1 <= "01"; -- S0
			else
				Sreg1 <= "11"; -- S2
			end if;
		when others =>   -- trap state
			Sreg1 <= "01"; -- S0
	end case;

	end if;
end if;
end process;

U_nRD1 <= Sreg0(0) when nReset_B = '1' and RnW = '1' else '1';
U_nWR1 <= Sreg0(0) when nReset_B = '1' and RnW = '0' else '1';
U_nADS <= Sreg1(0);

Article: 136260
Subject: Re: face recognition
From: Francois Choquette <fchoquette@gmail.com>
Date: Fri, 7 Nov 2008 15:31:50 -0800 (PST)
Links: << >>  << T >>  << A >>
> Well I think that designing a face-recognition system in VHDL (or
> Verilog) would be a huge waste of time and it would be really hard to
> do. There are tools for that, to automate conversion from Matlab to
> HDL (AccelDSP, system generator). I'm pretty sure that there are FPGA-
> neutral tools too for Matlab (that would work on both Altera and
> Xilinx)

Such as Synplify DSP, from Synplicity.  Supports all major devices
vendors, even ASIC technology.


Francois Choquette

Article: 136261
Subject: Re: 2D DCT algorithm
From: michaeldre@gmx.de (Michael Dreschmann)
Date: Sat, 08 Nov 2008 01:04:17 GMT
Links: << >>  << T >>  << A >>
On Tue, 04 Nov 2008 16:56:21 +0100, Guenter Dannoritzer
<kratfkryksqq@spammotel.com> wrote:

>http://www3.elphel.com/
>
>The source of those cameras is available as open source and one of the
>first camera models using M-JPEG has an encoder based on the XAPP610. I
>assume the author did get it to work.
>
>If not, there are several examples of JPEG encoders on opencores.

Thanks for the hint. I found a working DCT inside the
"Video compression systems" on opencores. The otherones on opencores
also didn't really work for me. Maybee I didn't gave them the right
control signals... I don't know. However now everything is working.

Regards,
 Michael

Article: 136262
Subject: Re: Setting FSM encoding in VHDL or in UCF for Xilinx
From: "KJ" <kkjennings@sbcglobal.net>
Date: Fri, 7 Nov 2008 20:11:42 -0500
Links: << >>  << T >>  << A >>

"Dale" <dale.prather@gmail.com> wrote in message 
news:58b81a5b-879b-49b9-b76b-f71530834267@d36g2000prf.googlegroups.com...

> The output of the FSM was glitching.  Specifically signals
> U_nWR1, U_nRD1 and U_ADS (seen below).  These are control signals for
> a UART.  When those signals glitch the UART's timing constraints
> aren't met and the communication with the UART fails.  Do you see a
> problem with how this state machine is coded?  Thanks again.
>

Given these equations, I can see good glitch potential for 'U_nRD1' and 
'U_nWR1' but not for 'U_nADS'.  The read and write controls are the output 
of combinatorial logic, not a flip flop which as I stated in the previous 
post can always glitch even if 'RnW' is also an output of a flip flop that 
is also clocked by 'H1'.  To test this hypothesis and see if this really is 
the root cause, you'll need to have a scope on 'U_nADS', 'U_nRD1' and 'RnW' 
(if that one is externally available) and trigger on a glitch on 'U_nRD1' 
(or instead of 'U_nRD1' use 'U_nWR1' if that is more likely to glitch).  I 
suspect you'll see that the glitch is occurring at either an edge on 
'U_nADS' or 'RnW'.

> U_nRD1 <= Sreg0(0) when nReset_B = '1' and RnW = '1' else '1';
> U_nWR1 <= Sreg0(0) when nReset_B = '1' and RnW = '0' else '1';
> U_nADS <= Sreg1(0);

To get rid of glitches on these two, you'll need to move them into the 
clocked process (and presumably change the logic somewhat if you don't want 
them to come out one H1 clock cycle later).  The strobe signal already is 
the output of a flip flop as far as synthesis is concerned because 
concurrent assignments like x <= y; or x <= not(y) are 'free' in the sense 
that they don't use any logic.

Another alternative is to move all three into the clocked process almost 
verbatim (change the 'when/else' into the equivalent 'if/else').  This 
delays all three control signals by the same amount so you haven't skewed 
the relative timing among the three.  But you'll probably also have to delay 
some address and data signals that are probably involved as well so that 
they stay in sync with the now delayed control signals.  But that's how you 
engineer the proper fix.

Along some other lines of thought that may or may not be applicable 
depending on what you find with the above...

Your state machine already has hard coded discrete values for the states so 
no matter what you do with synthesis attributes the logic implementing 
'Sreg0' and 'Sreg1' will not be any different so the whole path you've been 
going down in this post regarding trying to control the encoding isn't going 
to do anything to fix the problem.  If there are other places in your design 
where you do use an enumerated type, changing the encoding could affect that 
section which could then in turn impact timing of logic in this block which 
could be why you saw some difference.  This just an observation not any sort 
of problem.

Are all the state machine inputs synchronous to H1? (looks like just 
nReset_B, nPage3_244).  If not, I wouldn't really expect a glitch but you 
could end up transferring to the wrong state.  By 'glitch', I'm assuming you 
mean something that was just a few ns long, not something that lasted for an 
entire 'H1' clock cycle.  If it was a clock cycle wide type of glitch then 
this is not really what is normally called a 'glitch', but the problem then 
would be because the signal 'nPage3_244' is not synchronous to H1.

Somewhat along those lines as well...
- Is RnW synchronous to H1?  If not, then you'll see glitches because of the 
skew between Sreg0(0) and RnW.  RnW will also need to be synchronous to H1 
anyway in order to implement the change I mentioned above about moving the 
control signal logic into the clocked process.
- Is RnW a signal from this same design or does it come from a different 
part?  If from a different part, then how are you controlling skew on H1 
between these two devices?  Have you measured the skew?

Kevin Jennings 



Article: 136263
Subject: Data transfer between CPU and FPGA over PCI bus
From: KJ <lkjrsy@gmail.com>
Date: Fri, 7 Nov 2008 21:28:23 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi everyone.

I have a Xilinx ML555 and Linux as OS.
The job assigned to me is  linux programming for "Data transfer
between CPU and FPGA over PCI bus".
Someone already did the similar thing. Please help me.

General flow is like this.
(1) CPU sends data to FPGA
(2) FPGA do computations
(3) FPGA gives it back to CPU

What I want to ask is following.

(1) This is the first time for Linux programming.
     Where can I get the sample codes or reference?

(2) I think that initially FPGA chip is not configured.
    So How to configure it?  ( I mean that if I have a bitstream file
for FPGA, How can I configure FPGA with it?)

(3) If you have already done with similar job, plz give me an advice
about how to proceed.
    I have to do it myself, so even a little advice is big help for
me.

Thanks in advance.








Article: 136264
Subject: Altera Quartus II 8.1
From: Leon <leon355@btinternet.com>
Date: Fri, 7 Nov 2008 23:05:52 -0800 (PST)
Links: << >>  << T >>  << A >>
I've just downloaded the latest Altera Web Edition software. I was
pleased to see that they have removed the requirement for a license
that has to be renewed every six months. NIOS II is provided free,
also.

Leon

Article: 136265
Subject: Re: Tilera multicore replaces FPGA?
From: mentari <StephanusR@gmail.com>
Date: Fri, 7 Nov 2008 23:07:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 7, 11:09 pm, John_H <newsgr...@johnhandwork.com> wrote:
> Mentari -
>
> Please do us the favor of identifying yourself as an interested party
> in Tilera or tell us why you're posting here in comp.arch.fpga with
> absolutely no apparent history in this newsgroup.

I am not a engineer just somebody trying to figure out what it will
cost to pay an FPGA engineer to build a ODFM LTE or Wimax base station
that I can interface to any http://scratchpad.wikia.com/wiki/RfTransceiver

I have contacted http://scratchpad.wikia.com/wiki/SeaSolve but they
don't license their 802.16e MAC and PHY cores to the public only to
Telco's.  Is there some sort of conspiracy by Vodacom to prevent
people from building their own Wimax towers on say 450mhz like Flarion
FLASH-OFDM in the Nordic countries. ? How complicated is it our how
long will it take an engineer to build 802.16e MAC/PHY and at what
cost.

Please help me out.

Article: 136266
Subject: Re: Altera Quartus II 8.1
From: Leon <leon355@btinternet.com>
Date: Fri, 7 Nov 2008 23:10:15 -0800 (PST)
Links: << >>  << T >>  << A >>
On 8 Nov, 07:05, Leon <leon...@btinternet.com> wrote:
> I've just downloaded the latest Altera Web Edition software. I was
> pleased to see that they have removed the requirement for a license
> that has to be renewed every six months. NIOS II is provided free,
> also.
>
> Leon

Sorry, it's actually the NIOS II IDE that is available. I don't think
that the IP is free.

Leon

Article: 136267
Subject: Re: Altera Quartus II 8.1 (and Modelsim AE 6.3g)
From: "guestuser1" <guestuser1@nowhere.net>
Date: Fri, 7 Nov 2008 23:18:28 -0800
Links: << >>  << T >>  << A >>

"Leon" <leon355@btinternet.com> wrote in message 
news:72a2ae6c-52c3-416d-a075-9ad1e483de2c@b38g2000prf.googlegroups.com...
> On 8 Nov, 07:05, Leon <leon...@btinternet.com> wrote:
>> I've just downloaded the latest Altera Web Edition software. I was
>> pleased to see that they have removed the requirement for a license
>> that has to be renewed every six months. NIOS II is provided free,
>> also.
>>
>> Leon
>
> Sorry, it's actually the NIOS II IDE that is available. I don't think
> that the IP is free.
>
> Leon

The important thing, for me, is that Modelsim Altera-Edition has
*finally* been upgraded to a MODERN version (6.3g.)

Full end-to-end SYSTEMVERILOG in ALTERA tool-flow!
Simulation, RTL Synthesis, (basic) SV testbench.
(Advanced SV testbench still requires commercial license of
 Questasim + Modelsim/SE) 



Article: 136268
Subject: Re: Linux on Microblaze
From: "guestuser1" <guestuser1@nowhere.net>
Date: Fri, 7 Nov 2008 23:21:25 -0800
Links: << >>  << T >>  << A >>
"m" <martin.usenet@gmail.com> wrote in message 
news:3b479dc1-ac2d-41a0-8a44-9e8a51511309@a29g2000pra.googlegroups.com...
> I'm interested to hear from anyone who has experience implementing
> Linux on Microblaze.  How "smooth" is it?  What are the pitfalls?
> Limitations/issues?
>
> I am not talking about uClinux but rather the MMU version/s.
>
> I hear conflicting reports.  Hard processor vendors bash the heck out
> of it and tell us that it is an absolute nightmare (gee, I wonder
> why?).  Xilinx and the disti are telling us that all will be fine.

*ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
why would you even try to run a full Linux (MMU) kernel on it?

It may be academically interesting, but a far more practical setup
would use a Virtex4/FX (PowerPC-405) or a
Virtex5/FXT (PowerPC-440) 



Article: 136269
Subject: Synplicity/Synplify and Systemverilog support?
From: "guestuser1" <guestuser1@nowhere.net>
Date: Fri, 7 Nov 2008 23:23:18 -0800
Links: << >>  << T >>  << A >>
A year ago, I heard Synplicity's (RTL synth) Systemverilog support was
terrible.

Altera Quartus-II 8.1 supports Systemverilog quite well (interfaces,
enums, typedefs, unique/priority case, always_comb/always_ff, etc.)
Not everything yet, but very usable.

So how does the current version of Synplicity compare, in terms of
Systemverilog language support? 



Article: 136270
Subject: Re: Data transfer between CPU and FPGA over PCI bus
From: Andreas Ehliar <ehliar-nospam@isy.liu.se>
Date: Sat, 8 Nov 2008 11:09:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2008-11-08, KJ <lkjrsy@gmail.com> wrote:
> (1) This is the first time for Linux programming.
>      Where can I get the sample codes or reference?

It is actually not that hard to write a driver for Linux, but when doing
some initial experiments you don't even need a driver. I posted something
about this some time ago on c.a.f:

http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/5171491963302b63

/Andreas

Article: 136271
Subject: Re: Synplicity/Synplify and Systemverilog support?
From: filter001@desinformation.de
Date: Sat, 8 Nov 2008 07:37:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On 8 Nov., 08:23, "guestuser1" <guestus...@nowhere.net> wrote:
> A year ago, I heard Synplicity's (RTL synth) Systemverilog support was
> terrible.
>
> Altera Quartus-II 8.1 supports Systemverilog quite well (interfaces,
> enums, typedefs, unique/priority case, always_comb/always_ff, etc.)
> Not everything yet, but very usable.
>
> So how does the current version of Synplicity compare, in terms of
> Systemverilog language support?

9.4L tested still bad. Stay away from Synplicity for 1 year before
testing again. Maybe you'll discover its redundancy or even synplicity
will discover theirs.

Article: 136272
Subject: Re: Linux on Microblaze
From: cs_posting@hotmail.com
Date: Sat, 8 Nov 2008 09:18:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 8, 2:21 am, "guestuser1" <guestus...@nowhere.net> wrote:

> *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
> why would you even try to run a full Linux (MMU) kernel on it?

I would think that a system with an MMU would quite likely be more
efficient than one without, both in overhead for many operations
(which have to be done a bit oddly / emulated in uClinux without MMU)
and also in memory allocation efficiency.

As for why someone might run linux on an embedded system in general -
quite possibly because features and portability are more important
than raw speed.  Especially with FPGA fabric sitting right next door,
there's an implication that what has to be fast is done in logic,
while the processor and O/S are concerned with the complexities of
talking protocols to other computers, talking to humans, and quite
possibly running a fair amount of legacy code.

Yes, the hybrid powerPC/FPGAs would be an option there too, but as a
more specific part that may imply some undesired lock-in or at least
restriction on choices.   Anybody put a hard core processor in a
spartan/cyclone class part yet?   Wheras those are mainstays for
smaller soft-core systems.

Article: 136273
Subject: Re: Linux on Microblaze
From: David Brown <david.brown@hesbynett.removethisbit.no>
Date: Sat, 08 Nov 2008 21:20:41 +0100
Links: << >>  << T >>  << A >>
cs_posting@hotmail.com wrote:
> On Nov 8, 2:21 am, "guestuser1" <guestus...@nowhere.net> wrote:
> 
>> *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II)  is so slow,
>> why would you even try to run a full Linux (MMU) kernel on it?
> 
> I would think that a system with an MMU would quite likely be more
> efficient than one without, both in overhead for many operations
> (which have to be done a bit oddly / emulated in uClinux without MMU)
> and also in memory allocation efficiency.
> 

Generally speaking, running *without* an MMU is more efficient - people 
have been known to specifically choose no-MMU on devices such as large 
ARMs that have an MMU, because they want to avoid the overhead it needs. 
  In particular, an MMU will increase the latency for memory accesses 
(how significant this is depends on whether the MMU translation is 
before or after the cache, and on the rest of the memory access path), 
it will increase task switching time (since MMU setup needs to be 
swapped), and it means that all data sharing between processes needs to 
use "proper" channels - without an MMU, processes can cheat and directly 
access each others memory spaces.

For the particular case of memory allocation, however, an MMU will let 
the system use memory more efficiently.  It will also save space (and 
possibly time) if there are sections of code and data that are shared 
between processes but must appear as private.

> As for why someone might run linux on an embedded system in general -
> quite possibly because features and portability are more important
> than raw speed.  Especially with FPGA fabric sitting right next door,
> there's an implication that what has to be fast is done in logic,
> while the processor and O/S are concerned with the complexities of
> talking protocols to other computers, talking to humans, and quite
> possibly running a fair amount of legacy code.
> 
> Yes, the hybrid powerPC/FPGAs would be an option there too, but as a
> more specific part that may imply some undesired lock-in or at least
> restriction on choices.   Anybody put a hard core processor in a
> spartan/cyclone class part yet?   Wheras those are mainstays for
> smaller soft-core systems.

My understanding of Altera's FPGAs is that they have pretty much given 
up on using ARM hard-core processors, because the Nios / Nios II was 
actually faster for real use - the flexibility of memory bus 
arrangements, custom instructions, etc., meant that the space taken by 
the ARM core was simply not worth it.

Article: 136274
Subject: Re: RS-232 Bus controller design in VHDL
From: "ikki" <jasperng10@gmail.com>
Date: Sun, 09 Nov 2008 00:12:03 -0600
Links: << >>  << T >>  << A >>
>LittleAlex wrote:
>
>
>> Just to pick a nit....
>
>> RS-232 does have a protocol.  RTS-CTS, DSR-DTR, etc.  V.24 describes
>> the signal levels without mentioning the signal assertion/response.
>
>True, but much of it is rarely used.  In the days of half
>duplex communication with line turn around (the hardware
>could physically only transmit one direction at a time)
>that protocol was needed.  For connecting a terminal to
>a modem, or a computer to a printer, it isn't needed
>and isn't used.
>
>> So the OP is really saying "I want RS-232 protocol WITHOUT the
>> protocol".  Still a miss-formed question.
>
>See above.
>
>-- glen
>
>


thanks a bunch of all the comments here.... 
so far i manage to taken care of the reciever part of the rs232 bus
controller, but im still having problem with transmitter part..

any idea how to come out with the state machine of transmitter part ? ...


guidance is much appreciated




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