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 118875

Article: 118875
Subject: Re: lwIP RAW mode support for V4 temac
From: Sean Durkin <news_may07@durkin.de>
Date: Sat, 05 May 2007 12:36:02 +0200
Links: << >>  << T >>  << A >>
Patrick Dubois wrote:
> Hello,
> 
> Does anyone know of an example using lwIP in RAW mode with the
> Virtex-4 temac? From what I understand, the lwIP temac port seemingly
> only supports lwIP in sockets mode with xilkernel.
> 
> I don't quite understand the lack of temac support at the software
> level. What are people doing when using temac on the V4? Is everyone
> using lwIP in sockets mode? No one is using raw lwIP on the V4?
At X-Fest they said that raw mode will be available with EDK9.2, which
is supposed to be available sometime after ISE9.2, which is scheduled
for September, IIRC.

-- 
My email address is only valid until the end of the month.
Try figuring out what the address is going to be after that...

Article: 118876
Subject: Re: debounce state diagram FSM
From: Fred Bloggs <nospam@nospam.com>
Date: Sat, 05 May 2007 12:51:15 GMT
Links: << >>  << T >>  << A >>



>>>>>>>>>>  derogatory crap deleted by archive owner


Article: 118877
Subject: Re: debounce state diagram FSM
From: Richard Heathfield <rjh@see.sig.invalid>
Date: Sat, 05 May 2007 13:08:08 +0000
Links: << >>  << T >>  << A >>
Fred Bloggs said:

>>>>>>>>>>  derogatory crap deleted by archive owner


Well well well, another entry for the killfile. Racism is a clear sign 
of stupidity. Were stupidity curable by reason, that might be another 
matter, but it isn't, so it isn't.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Article: 118878
Subject: Re: debounce state diagram FSM
From: Fred Bloggs <nospam@nospam.com>
Date: Sat, 05 May 2007 13:12:30 GMT
Links: << >>  << T >>  << A >>


Richard Heathfield wrote:
> Fred Bloggs said:
> 
> 
>>>>>>>>>>  derogatory crap deleted by archive owner
> 
> Well well well, another entry for the killfile. Racism is a clear sign 
> of stupidity. Were stupidity curable by reason, that might be another 
> matter, but it isn't, so it isn't.
> 

Stupidity is more often demonstrated by those who claim to see "a clear 
sign" all the time...


Article: 118879
Subject: Re: debounce state diagram FSM
From: "christian.bau" <christian.bau@cbau.wanadoo.co.uk>
Date: 5 May 2007 07:36:21 -0700
Links: << >>  << T >>  << A >>
On Apr 29, 7:32 pm, Anson.Stugg...@gmail.com wrote:
> I'm designing a debounce filter using Finite State Machine. The FSM
> behavior is it follows the inital input bit and thinks that's real
> output until it receives 3 consecutive same bits and it changes output
> to that 3 consecutive bit until next 3 consecutive bits are received.
> A reset will set the FSM to output 1s until it receives the correct
> input and ouput.
>
> This is the test sequence with input and correct output.
>
> 1 0 0 1 0 1 0 0 0 1 0 1 1 1   (input)
> 1 1 1 1 1 1 1 1 0 0 0 0 0 1   (output)
>
> The state diagram I came up has 6 states and it's named SEE1, SEE11,
> SEE111, SEE0, SEE00, SEE000. I am getting stuck at 11th bit, a 0 in
> the input. Because it just came from SEE1 and before SEE1, it came
> from SEE000, so at SEE1 it can not change ouput to 1 which is what I
> have specified that state's ouput to be.
>
> Anyone knows how to solve this problem? Or maybe there's other better
> ways to design the state diagram?

Just describe the states in C first: "output" is the debounced output
value; "contradictions" is the number of bits that were input that
could convince you to switch the output state.

int output = 1; // 0 or 1
int contradicitions = 0; // 0, 1, or 2

for (;;) {
  int input = get_input ();
  if (input == output) contradictions = 0;
  else if (contradictions < 2) ++contradictions;
  else { output = input; contradictions = 0; }
}

Clearly there are six states; fill in the transitions according to
what the algorithm does.


Article: 118880
Subject: Re: Atom HDL
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Sat, 05 May 2007 18:22:57 +0200
Links: << >>  << T >>  << A >>
Tom wrote:

> I don't have experience with MyHDL, so my statements may need to be
> qualified.  From what
> I gather, MyHDL very closely approximates the semantics of Verilog
> (@always(clock.posedge)).

VHDL semantics actually, where it really matters (i.e. a clear
separation between Signal objects and plain variables.)

> Therefore I suspect, in terms of synthesis, MyHDL is still at RTL.
> 
> Where MyHDL shines, is it's ability to simulate within it's host
> language, Python.
> If locked in a room with SystemVerilog and Python, I'd take Python any
> day.  If offered
> OCaml or Haskell, I'll always reach for higher-order functional
> languages.

I believe that the usage of the term "RTL" creates a lot of confusion,
as I hope to clarify below.

The way I see it, there are two schools of thought in HDLs, depending
on the way they treat events and (hardware) registers:

* Type 1: explicit registers & implicit events
HDLs based on functional languages seem the be all of this type.

* Type 2: explicit events & implicit registers
This is the model of HDLs such as VHDL and Verilog (and MyHDL).
VHDL signals and variables, and Verilog regs, are all objects
that may become registers, or not, in hardware, depending on
how they are used in the code. Thus, registers are implicit.

Regarding the term RTL - Register Transfer Language - it seems clear
that it's appropriate terminology for type 1 languages. But how
could it be meaningful for type 2 languages - languages
without "register objects"?

It might even be argued that type 2 languages concentrate more
on hardware behavior instead of implementation, and therefore
should be considered "higher level".

More interestingly, there seems to be correlation between the
language type and the kind of semantics provided. Clearly,
all HDLs need concurrent statements - such as VHDL processes
and Verilog always blocks. However, type 1 languages seem
to stop there, while type 2 languages provide sequential
statements also (inside processes and always blocks).

So in my view, type 2 semantics is a superset of type 1.
Type 2 is more successful simply because it is more
powerful.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Article: 118881
Subject: Re: Atom HDL
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 05 May 2007 11:29:22 -0700
Links: << >>  << T >>  << A >>
Jan Decaluwe wrote:

> It might even be argued that type 2 languages concentrate more
> on hardware behavior instead of implementation, and therefore
> should be considered "higher level".

I agree. Inside a synchronous block/process of
a Type 2 RTL description, I can be as procedural
as I like. Synthesis will take care of the pesky
details of inferring the LUTs, registers,
and those wires to hook them up.

However, when it comes to wiring up blocks and modules,
my procedural inclinations are thwarted.
I'm ready for Type 3.

  -- Mike Treseler

Article: 118882
Subject: Re: Atom HDL
From: "evilkidder@googlemail.com" <evilkidder@googlemail.com>
Date: 5 May 2007 11:52:30 -0700
Links: << >>  << T >>  << A >>
>
> I believe that the usage of the term "RTL" creates a lot of confusion,
> as I hope to clarify below.
>
> The way I see it, there are two schools of thought in HDLs, depending
> on the way they treat events and (hardware) registers:
>
> * Type 1: explicit registers & implicit events
> HDLs based on functional languages seem the be all of this type.
>
> * Type 2: explicit events & implicit registers
> This is the model of HDLs such as VHDL and Verilog (and MyHDL).
> VHDL signals and variables, and Verilog regs, are all objects
> that may become registers, or not, in hardware, depending on
> how they are used in the code. Thus, registers are implicit.
>
> Regarding the term RTL - Register Transfer Language - it seems clear
> that it's appropriate terminology for type 1 languages. But how
> could it be meaningful for type 2 languages - languages
> without "register objects"?


I think it is.  For hardware that is actually synthesizable, there are
really only two standard event models which are useful:

always @*
always @(posedge clock[, posedge reset])

Thus we still only really have combinatorial or registered logic.  It
strikes me as more confusing than useful that "regs" or "signals" (or
"variables") can be both.

The one grey area is describing latches.  In all my FPGA designs I
have never (intentionally) used them.  In the one ASIC project I
worked on that did allow them, they had to be instantiated as a
library component which is easily supported by most HDLs.


>
> It might even be argued that type 2 languages concentrate more
> on hardware behavior instead of implementation, and therefore
> should be considered "higher level".
>


What in particular do think makes it higher level?  At the end of the
day we still only desribe one of two things - combinatorial logic or
registers.  The only difference is in type 1 is it defined when the
"object" is created and in type 2 it is inferred from it's
environment.  The later seems more clumsy to me.


> More interestingly, there seems to be correlation between the
> language type and the kind of semantics provided. Clearly,
> all HDLs need concurrent statements - such as VHDL processes
> and Verilog always blocks. However, type 1 languages seem
> to stop there, while type 2 languages provide sequential
> statements also (inside processes and always blocks).
>


I agree that the sequential style of coding is useful, however, it is
available in both HDCaml and HDFS.  In fact the model provided there
is, in my opinion, more powerful than VHDL and Verilog (I dont know
about MyHDL) as the constructs can be manipulated programatically by
the host language.

The abstraction provided by atom is a whole different kettle of fish
which significantly changes the way you think about circuit design.
Of all the HDLs mentioned so far it's the only one I consider can
truly be called "higher level".

Please dont for a second consider this any sort of criticism of MyHDL
- it's a very good idea with a great implementation.  For my part,
however, I prefer the functional programming approach - I just wish
more people agreed...

Cheers,

Andy.


Article: 118883
Subject: EDK OPB_SPI in slave mode
From: Antti <Antti.Lukats@xilant.com>
Date: 5 May 2007 11:59:39 -0700
Links: << >>  << T >>  << A >>
Hi

having trouble :(, all Xilinx and example only explain the used of
OPB_SPI as master, as slave it doesnt want to work, any tricks or
special care required?

Antti


Article: 118884
Subject: Re: OPB Master Peripheral
From: Guru <ales.gorkic@email.si>
Date: 5 May 2007 12:39:08 -0700
Links: << >>  << T >>  << A >>
On May 3, 1:37 am, chakra <narashim...@gmail.com> wrote:
> Hello all, I am working on a project, in which am trying to make
> OV7660 camera protoboard to talk to  ML300 Xilinx FPGA board.I have a
> general question regarding OPB bus.
>
> Here is the set up:  I am building a OPB Master peripheral which
> directly talks to camera (8 data, vsync, Href and Pixclk) via GPIO
> pins on the ML300 board. The same master peripheral talks to OPB DDR
> SDRAM which is a slave connected to the OPB Bus. the Master peripheral
> acquires the data from the camera frame after frame and stores them in
> the DDR(currently am overwriting the image over and over at the same
> address stack in DDR)
>
> Question:: is there a limitation in terms of "clock cycles" to hold
> the M_Select/M_Buslock high when given OPB_Mgrant by the opb BUS. Like
> for example "..on a particular time once the OPB gives M_Grant a
> Master peripheral can hold the M_Select and M_Buslock high  only for
> 16 clock cycles...". is there some limitation like the above?
>
> i am holding the M_Buslock and M_Select high till the transfer is
> complete. and it takes close to 640*480*2 pixclk to collect one frame
> of data from the camera to DDR SDRAM. Once the transfer is complete I
> do release those signals and pull M_Dbus to ground. I read through the
> Buslock operation given in the OPB manual by IBM and they seem to be
> vague on this issue.
>
> algorithm might look like this
> A. Master peripheral holds M_Request high
> B. OPB gives OPB_Mgrant
> C. Master peripheral pulls M_Request low and holds M_select high to
> assert OPB bus and take control of the bus. and once transfer is done
> D. Master peripheral pulls M_Select Low
>
> If you can help me in this regard it will be very helpful for the
> success of my project

Dear Chakra,

I build a peripheral like this about a year ago.
The principle is about the same what you suggested, you just forgot
some details:
A. Master peripheral holds M_Request high
B. OPB gives OPB_Mgrant
C. Master peripheral pulls M_Request low and holds M_select,
M_seqAddr, M_BE and M_busLock high to
assert OPB bus and take control of the bus. You should increment
address for every OPB_xferAck received.
D. One cycle before the end of burst pull the  M_seqAddr and M_seqAddr
low
E. Master peripheral pulls M_Select and M_BE Low

There is NO limitation for burst size in clock cycles. The only thing
which limits the burst size is a OPB_retry signal which is asserted
after OPB_xferAck going low. This is usually a consequence of RAM
refresh. When the OPB_retry happens in the state C then cancel
transfer and retry (state A).
If you receive OPB_errAck or OPB_timeout then immediatelly cancel
transfer.

Don't hesitate to contact me for further questions.

Good luck,

Guru


Article: 118885
Subject: Re: Atom HDL
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Sat, 05 May 2007 21:46:47 +0200
Links: << >>  << T >>  << A >>
evilkidder@googlemail.com wrote:

> For hardware that is actually synthesizable, there are
> really only two standard event models which are useful:
> 
> always @*
> always @(posedge clock[, posedge reset])
> 
> Thus we still only really have combinatorial or registered logic.  It
> strikes me as more confusing than useful that "regs" or "signals" (or
> "variables") can be both.

I have two points to add to the confusion:

* the form "always @(posedge clock[, posedge reset])" is not just for
registered logic, but for combinatorial logic as well. With a few exceptions,
it's probably the only template that you really need.

* it's not just that one variable can be combinatorial and another registered;
to make things worse :-) the *same* variable can be *both*!

For a practical example (in MyHDL) on how this can be useful, see:
     http://myhdl.jandecaluwe.com/doku.php/cookbook:jc2

How to solve the confusion? Replace the "Think hardware" paradigm with
"Understand your compiler" (the compiler being the synthesis tool).
Similar to what good software engineers do, you have to understand what
type of coding styles are handled efficiently by the compiler, even if
at first you don't exactly understand how.

Once you do that the confusion disappears and a whole new world of
elegant coding solutions becomes available. And you even start to
understand how the compiler works - it's not *that* hard after all :-)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Article: 118886
Subject: Re: Xilinx software quality - how low can it go ?!
From: fpga_toys@yahoo.com
Date: 5 May 2007 14:04:27 -0700
Links: << >>  << T >>  << A >>
On May 3, 8:25 am, Frank Buss <f...@frank-buss.de> wrote:
> Would be a good idea to combine both designing tools (but using the GUI of
> Quartus, because it's nicer than the ISE GUI) and open source it. In the
> end this would lead to less development cost for all: the FPGA companies,
> because they don't need to write both the same things and for users of the
> program, because they can help bugfixing it and using a more stable
> program. Company secrets could be moved to plugin modules.

When their management learn the products can be supported better with
the same number of people leading the project, and the developers
learn they are not likely to lose their jobs, it should be an easier
decision. Plus they get aditional volunteer labor for design, coding,
AND TESTING that they can not afford now. Even large customers, which
have significant internal development staff see less project risks
when they can fix mission critical bugs on the fly, rather than have
the whole project grind to a stop while pressing the vendor hard for a
fix.

Another benefit, is recruiting new hires can be taken from the
volunteer developer pool as needed, and they are already several
months ahead of the learning curve that it takes to get a new hire
productive.

It's hard sometimes to understand why they think remaining in the
stone age is better.


Article: 118887
Subject: Re: Atom HDL
From: Tom <tomahawkins@gmail.com>
Date: 6 May 2007 09:49:50 -0700
Links: << >>  << T >>  << A >>
On May 5, 4:41 am, Edmond Cot=E9 <edmond.c...@gmail.com> wrote:
> On May 4, 12:47 am, Tom <tomahawk...@gmail.com> wrote:
>
> > Atom is a new high-level hardware description language embedded in
> > the functional language Haskell.  Atom compiles circuit descriptions
> > in conditional term rewriting systems down to Verilog and VHDL
> > for IC simulation, verification, and synthesis.
>
> I'll take a look...
>
> Sounds a lot like Bluespec, what can you say about the differences
> between the two?
>
> Edmond

The ideas are the same, but Atom lags behind Bluespec on nearly every
front.  Atom has:

- no support for multiple clock domains
- no assertions
- no input language support for SystemVerilog or SystemC
- incomprehensible HDL code generation
- minimal circuit optimization
- limited design capacity

If you are looking for a behavioral synthesis tool for professional
grade ASIC design, Bluespec is the best choice on the market.  But if
you're a hobbyist without a CAD budget, Atom provides a glimpse of the
future of IC design.

-Tom

PS: This is just speculation, but Atom's rule scheduling may be
significantly different Bluespec -- I see no mention of it in the MIT
research papers.  For those interested, Atom assigns a global, linear
priority to rules.  To maximize rule concurrency, Atom prioritizes the
rules to minimize the number of lower priority rules that write data
read by higher priority rules.  When a higher
priority rule writes data read by a lower priority rule, but not vice
versa, this forms a "sequentially composable" relationship, and
thus the two rules can execute in the same clock cycle.  In this
framework, rule scheduling becomes equivalent to the Feedback Arc Set
problem (http://en.wikipedia.org/wiki/Feedback_arc_set), where an arc
is a data dependency between two rules.

Unfortunately, many of the arcs in a rule-data dependency graph are
irrelevant, since some rules can not be enabled at the same time.  For
example, take an FSM, where the FSM is modeled with one rule for every
state:

stoplightController :: System ()
stoplightController =3D do

  state <- reg "state" 2 0
  let red    =3D constant 2 0
      yellow =3D constant 2 1
      green  =3D constant 2 2

  rule "onRed" $ do
    when (value state =3D=3D. red)
    ...
    state <=3D=3D green

  rule "onGreen" $ do
    when (value state =3D=3D. green)
    ...
    state <=3D=3D yellow

  rule "onYellow" $ do
    when (value state =3D=3D. yellow)
    ...
    state <=3D=3D red

For the stoplightController, the onRed, onGreen, and onYellow rules
will never be enabled at the same time.  Therefore, any arcs between
these rules should be removed from the rule-data dependency graph
before optimizing the schedule.  To find these mutually exclusive
rules, Atom analyzes the rule logic with it's own algorithms and with
the help of the MiniSat external SAT solver.  There's no guarantee it
finds all mutually exclusive rules, but it does a pretty good job.




Article: 118888
Subject: Re: picoblaze C compiler download wanted
From: fpga_toys@yahoo.com
Date: 6 May 2007 10:34:41 -0700
Links: << >>  << T >>  << A >>
On May 4, 2:27 am, Francesco <francesco_poder...@yahoo.com> wrote:
>  I will post in this forum the name of the domain

Any thoughts about merging this work with http://sourceforge.net/projects/sdcc/
to leverage maintainence and provide cross device protability for
libraries, applications, and tools?


Article: 118889
Subject: Re: Atom HDL
From: Paul Taylor <paul_ng_pls_rem@tiscali.co.uk>
Date: Sun, 06 May 2007 18:57:14 +0100
Links: << >>  << T >>  << A >>
On Sat, 05 May 2007 11:52:30 -0700, evilkidder@googlemail.com wrote:

> What in particular do think makes it higher level?  At the end of the
> day we still only desribe one of two things - combinatorial logic or
> registers.  The only difference is in type 1 is it defined when the
> "object" is created and in type 2 it is inferred from it's
> environment.  The later seems more clumsy to me.

I would tend to agree. I have been working on a HDL (which is stalled
because some aspects of it don't scale well!) but explicitly declaring
registers is something that I like. From my stuff:

reg myRegister[%8]; # an eight bit register
reg myRegister[%8] = dataIn when load; # loadable register
reg myCounter[%8] = next; # 8-bit binary counter that just counts up
reg myCounter[%8] = { next when up; prev when dn; } # up/dn counter
gray myCounter = next; # gray counter that just counts up
johnson myCounter = { 0 when rst; next when up; } # guess what it does?
onehot myCounter = { async 0 when rst; next when up; } # ditto
shift reg myShReg[%8] = next when shft with myShReg[0] = serialIn; # ditto

Finally an example that creates two counters which are incremented in
different states of a state machine:

# the two counters
reg myCounterA[%4], myCounterB[%8] = { node up; next when up; }

# the state machine
reg myStateMachine[] = {
  : myCounterA.up = 1; next;
  : myCounterB.up = 1; prev;
}

Regards,

Paul.









Article: 118890
Subject: Re: Atom HDL
From: Paul Taylor <paul_ng_pls_rem@tiscali.co.uk>
Date: Sun, 06 May 2007 19:11:56 +0100
Links: << >>  << T >>  << A >>
On Sun, 06 May 2007 18:57:14 +0100, Paul Taylor wrote:

too hasty in posting....

> gray myCounter = next; # gray counter that just counts up
> johnson myCounter = { 0 when rst; next when up; } # guess what it does?
> onehot myCounter = { async 0 when rst; next when up; } # ditto

should be as: 

gray reg myCounter[%4] = next; 
johnson reg myCounter[%4] = { 0 when rst; next when up; }
onehot reg myCounter[%4] = { async 0 when rst; next when up; } 

gray, johnson, onehot provide context for the next and prev keywords
(amongst other things)

Regards,

Paul.


Article: 118891
Subject: V5 LVPECL Inputs
From: Test01 <cpandya@yahoo.com>
Date: Sun, 6 May 2007 12:25:54 -0700
Links: << >>  << T >>  << A >>
I have a differential driver with Vcm = 3.025V and Differential voltage of 1100mv. Thus each arm of the differential signal has 550 mV swing and Vcm being Vcc - 0.275V (3.3 - 0.275 = 3.025V).

Looking at the V5 LVPECL input specification, the Vicm can cary from 0.6V to 2.2V. This does not match with the Non Xiilnx output driver with Vcm = 3.025V

Is there any way I can ake this work without adding external termination?

Thanks for your valuable feedback.

Test01

Article: 118892
Subject: Re: V5 LVPECL Inputs
From: Peter Alfke <alfke@sbcglobal.net>
Date: 6 May 2007 14:34:47 -0700
Links: << >>  << T >>  << A >>
On May 6, 12:25 pm, Test01 <cpan...@yahoo.com> wrote:
> I have a differential driver with Vcm = 3.025V and Differential voltage of 1100mv. Thus each arm of the differential signal has 550 mV swing and Vcm being Vcc - 0.275V (3.3 - 0.275 = 3.025V).
>
> Looking at the V5 LVPECL input specification, the Vicm can cary from 0.6V to 2.2V. This does not match with the Non Xiilnx output driver with Vcm = 3.025V
>
> Is there any way I can ake this work without adding external termination?
>
> Thanks for your valuable feedback.
>
> Test01

You claim that the output voltage , at its most positive, is 275 mV
more positive than its Vcc.
Can that be true?
Peter Alfke, from home


Article: 118893
Subject: Re: V5 LVPECL Inputs
From: John_H <newsgroup@johnhandwork.com>
Date: Sun, 06 May 2007 22:10:57 GMT
Links: << >>  << T >>  << A >>
Test01 wrote:
> I have a differential driver with Vcm = 3.025V and Differential voltage of 1100mv. Thus each arm of the differential signal has 550 mV swing and Vcm being Vcc - 0.275V (3.3 - 0.275 = 3.025V).
> 
> Looking at the V5 LVPECL input specification, the Vicm can cary from 0.6V to 2.2V. This does not match with the Non Xiilnx output driver with Vcm = 3.025V
> 
> Is there any way I can ake this work without adding external termination?
> 
> Thanks for your valuable feedback.
> 
> Test01

Your non-Xilinx drivers aren't LVPECL, are they?
What is your driver?
Does its common-mode range have to be so high?

Article: 118894
Subject: Re: Spartan 3A Starter Kit Multiboot Demo Config 4 Display Problem
From: "Bryan" <sfoo@xilinx.com>
Date: Mon, 7 May 2007 10:43:44 +0800
Links: << >>  << T >>  << A >>
Hi all, sorry for the confusion, anyway to answer any doubts, the said demo 
was the one as described by Eric Crabill where you can edit the picture from 
the camera on the video display. The hardware used is also as described by 
Eric. This design i am not sure why is it not posted yet. Well i do work in 
Xilinx Asia Pacific and i have posted internal tech support as well but no 
reply yet. Also I did not see this demo at XFEST , rather tomorrow is XFEST 
@ Singapore and I am manning the booth, so that is why i sound so troubled 
and urgent. Meanwhile i have contacted faes and sales rep as well so 
hopefully it will all work out.


(P.S: I am not that well versed in FPGA system level design yet, just a 
newbie)


"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1178345956.666826.284270@q75g2000hsh.googlegroups.com...
> Eric Crabill schrieb:
>> Hi Jim,
>>
>> I don't usually look at the message headers, because it plays no role in 
>> my
>> deciding to answer a question.  Maybe Bryan does work with/for Xilinx! 
>> In
>> any case, Bryan, I hope I answered your question.
>>
>> You can get a working DDR2 interface from MIG 1.7 specifically for the
>> Spartan-3A Starter Kit.  There's also a working design derived from that 
>> in
>> the board test design that is posted on the Spartan-3A Starter Kit 
>> reference
>> design page.  I think what some previous posters wanted was more than
>> "working", rather a "stress test" or something that really demonstrates 
>> the
>> bandwidth of the memory interface.  I agree that such a demo or reference
>> design would have value.  Do I have any comments/release schedules to 
>> share?
>> No, sorry.
>>
>> Eric
>>
>> "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message
>> news:463b885f$1@clear.net.nz...
>> > Eric Crabill wrote:
>> >> Hi Bryan,
>> >>
>> >> Maybe you saw the video pass through design at an XFEST event or at 
>> >> the
>> >> Spartan-3AN press release event?  Otherwise, I am not sure how you 
>> >> would
>> >> know it exists.  If you are looking for that design, please contact 
>> >> your
>> >> local FAE or sales representative for assistance.  I am not sure 
>> >> if/when
>> >> this design will be posted.
>> >
>> > :) Err..,  I think he IS the local FAE / Sales rep, as his address 
>> > claims
>> > Xilinx ?.
>> >
>> > It maybe that it was an 'oops' posting, meant to go upstream inside
>> > Xilinx. [yes, does happen sometimes...]
>> >
>> > Any comments/release schedules re Antti's questions about DDR2 working
>> > examples on 3A demo system ?
>> >
>> > -jg
>> >
>
> Eric,
>
> it looks like I am missing something :(
>
> 1) the only thing at X-Fest was the rotazoom that takes images from
> NOR flash
> no video pass through demo (at X-Fest in Munich)
>
> 2) the only "derived" DDR2 design seems to be board test design where
> PicoBlaze
> reads out the MIG testbench error led status and displays p or f on
> hyperterminal -
> is this the MIG derived design you have been referreing to, or is
> there some more
> functional design available?
>
> Antti
> 



Article: 118895
Subject: Re: Spartan 3A Starter Kit Multiboot Demo Config 4 Display Problem
From: "Eric Crabill" <eric.crabill@xilinx.com>
Date: Sun, 6 May 2007 20:28:41 -0700
Links: << >>  << T >>  << A >>
> the only "derived" DDR2 design seems to be board test design where
> PicoBlaze reads out the MIG testbench error led status and displays
> p or f on hyperterminal is this the MIG derived design you have been
> referreing to

Yes. 



Article: 118896
Subject: Re: Spartan 3A Starter Kit Multiboot Demo Config 4 Display Problem
From: Antti <Antti.Lukats@xilant.com>
Date: 6 May 2007 23:44:01 -0700
Links: << >>  << T >>  << A >>
On 7 Mai, 04:43, "Bryan" <s...@xilinx.com> wrote:
> Hi all, sorry for the confusion, anyway to answer any doubts, the said demo
> was the one as described by Eric Crabill where you can edit the picture from
> the camera on the video display. The hardware used is also as described by
> Eric. This design i am not sure why is it not posted yet. Well i do work in
> Xilinx Asia Pacific and i have posted internal tech support as well but no
> reply yet. Also I did not see this demo at XFEST , rather tomorrow is XFEST
> @ Singapore and I am manning the booth, so that is why i sound so troubled
> and urgent. Meanwhile i have contacted faes and sales rep as well so
> hopefully it will all work out.
>
> (P.S: I am not that well versed in FPGA system level design yet, just a
> newbie)

Hi

dont worry so much - when I was at X-Fest munich then the first
question I asked at Spartan-3A booth:
"may i see the DNA demo?" caused the support personal to seek for
printed documents and reading them (means they had not done their
homework).

While seeing the S3A board first time I figured out the way to start
the DNA demo before the support personel found it the printed
documents.

So it is good that you are trying todo your homework ahead of time, it
may avoid trouble with difficult questions at the booth. I hope that
you do not get trouble asking a "xilinx internal support question" at
public newsgroups, as in many times c.a.f. can deliver results WAY
faster then Xilinx WebCase.

sidenote to Xilinx: there is room for improvment for information flow
within Xilinx? (To improve the ability of Xilinx employees to support
Xilinx customers)

Antti


Article: 118897
Subject: Re: My Dear Spartan-3A, Please Please WAKE UP!
From: Zara <me_zara@dea.spamcon.org>
Date: Mon, 07 May 2007 09:41:09 +0200
Links: << >>  << T >>  << A >>
On 2 May 2007 06:21:32 -0700, Antti <Antti.Lukats@xilant.com> wrote:

>After giving up the search for Xilinx supplied MicroBlaze reference
>designs for Xilinx Spartan-3A kit, I made the reference design using
>BSB in EDK 9.1SP1.
>
>No problem encountered until the attempt to load the bitstream into
>Spartan-3A
>
>Bitstream download succeeded, Done also OK.
>Reading back JTAG Status from impact tells me EVERYTHING is OK!
>
>But... init LED is half-way dimmed and "AWAKE" LED is off, this
>behavior is the same no matter the "SUSPEND" input switch position. I
>have not enabled suspend in the design, so to my understanding the
>bitstream should come up alive?
>
>But it doesnt. Is Spartan-3A in some undocumented deep sleep mode?
>
>I was really hoping to see "Hello Spartan-3A" on the terminal, or at
>least the LEDs blinking.
>But all that happens is DONE=ON, AWAKE=OFF, INIT=30% dimmed.
>
>I will fight again tomorrow, maybe I get some bright how to wake up
>Spartan-3A when I sleep.
>
>Antti

I am working with S3ASK, with microblaze and have no problema at all.
Maybe you forgot to set the configuration switches to JTAG? I had that
problem too!

Best regards

zara

Article: 118898
Subject: Re: My Dear Spartan-3A, Please Please WAKE UP!
From: Antti <Antti.Lukats@xilant.com>
Date: 7 May 2007 01:10:36 -0700
Links: << >>  << T >>  << A >>
On 7 Mai, 09:41, Zara <me_z...@dea.spamcon.org> wrote:
> On 2 May 2007 06:21:32 -0700, Antti <Antti.Luk...@xilant.com> wrote:
>
> >After giving up the search for Xilinx supplied MicroBlaze reference
> >designs for Xilinx Spartan-3A kit, I made the reference design using
> >BSB in EDK 9.1SP1.
>
> >No problem encountered until the attempt to load the bitstream into
> >Spartan-3A
>
> >Bitstream download succeeded, Done also OK.
> >Reading back JTAG Status from impact tells me EVERYTHING is OK!
>
> >But... init LED is half-way dimmed and "AWAKE" LED is off, this
> >behavior is the same no matter the "SUSPEND" input switch position. I
> >have not enabled suspend in the design, so to my understanding the
> >bitstream should come up alive?
>
> >But it doesnt. Is Spartan-3A in some undocumented deep sleep mode?
>
> >I was really hoping to see "Hello Spartan-3A" on the terminal, or at
> >least the LEDs blinking.
> >But all that happens is DONE=ON, AWAKE=OFF, INIT=30% dimmed.
>
> >I will fight again tomorrow, maybe I get some bright how to wake up
> >Spartan-3A when I sleep.
>
> >Antti
>
> I am working with S3ASK, with microblaze and have no problema at all.
> Maybe you forgot to set the configuration switches to JTAG? I had that
> problem too!
>
> Best regards
>
> zara- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

nono - there was NO PROBLEM..:)
I was just confused that with default setting the INIT LED is 50% on
state..
this is however NORMAL behaviour, I did not recognize that, and
assumed something was wrong.

all things work ok on s3astarter, including MicroBlaze - well without
DDR2 support :(

Antti








Article: 118899
Subject: Disable Readback (XILINX)?
From: "Sven" <sven@is.com>
Date: Mon, 7 May 2007 11:22:05 +0200
Links: << >>  << T >>  << A >>
If i have an external SPI FLASH connected to the FPGA and uses 'Disable 
Readback' in the configuration. What does it do exactly?

It is still possible to read the SPI FLASH externall?





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