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 138025

Article: 138025
Subject: Re: Why the second flip-flop in Virtex-6?
From: -jg <Jim.Granville@gmail.com>
Date: Wed, 4 Feb 2009 02:30:06 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 11:15=A0pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
> -jg wrote:
> > That's =A0a large market to isolate your devices from - one hopes the
> > few picoseconds of speed that might have gained, turn out to be wrth
> > it!! :)
>
> It more a question of die space. 3.3v tolerant IO is huge in 40/45nm.
> In V6 they are trying to reach the high end of IO and LUT counts. On
> the other hand with S6 the LUT counts are not that high and also the IO
> count is lower than in V6 so they can waste space for the IO.

Die Size, are you sure ?
- My understanding is Oxide thickness is what primarily determines IO
Voltage Specs.

Die area (PAD IO area) more determines drive current.

-jg

Article: 138026
Subject: Choosing RAM for microblaze and connecting it.
From: Jan <1@2.3>
Date: Wed, 04 Feb 2009 11:38:17 +0100
Links: << >>  << T >>  << A >>
Dear all,

I'm working on a small project where I need a microblaze with external 
memory.

It needs to be cheep so I guess SDRAM is the right choice? I don't need 
much memory.

My next problem is how to connect it to the FPGA so microblaze can use 
it. I can't seem to find any detailed documentation. Maybe one of you 
have done the trick before and know where to find the information.

Thanks in advance!

Regards
   Jan

Article: 138027
Subject: Re: xilinx platform usb cable linux troubles
From: luudee <rudolf.usselmann@gmail.com>
Date: Wed, 4 Feb 2009 04:08:36 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 3:19=A0pm, "h.e." <h...@thisisnovalidaddress.net> wrote:
>
> This is my log with ise10.1 sp3 and libusb, maybe it helps to update the
> firmware files being loaded? do you use the udev-rules suggested by
> xilinx? ($XILINX/bin/lin64/xusbdfwu.rules)


Thanks for the reply h.e.

Yeah, I am using the udev, I think the installer sets that up
during install. I double checked and it is all there.

I also reinstalled ISE, and ISE+sp3. The origin ISE works
just fine with the cable, I can program everything. It's the
SP3 that broke something ...

Best regards,
rudi

Article: 138028
Subject: Re: xilinx platform usb cable linux troubles
From: "h.e." <he@thisisnovalidaddress.net>
Date: Wed, 04 Feb 2009 13:27:16 +0100
Links: << >>  << T >>  << A >>
luudee schrieb:
> On Feb 4, 3:19 pm, "h.e." <h...@thisisnovalidaddress.net> wrote:
>> This is my log with ise10.1 sp3 and libusb, maybe it helps to update the
>> firmware files being loaded? do you use the udev-rules suggested by
>> xilinx? ($XILINX/bin/lin64/xusbdfwu.rules)
> 
> 
> Thanks for the reply h.e.
> 
> Yeah, I am using the udev, I think the installer sets that up
> during install. I double checked and it is all there.
> 
> I also reinstalled ISE, and ISE+sp3. The origin ISE works
> just fine with the cable, I can program everything. It's the
> SP3 that broke something ...
> 
> Best regards,
> rudi

did you try the firmware version 1100? I had problems with older
versions, too...

Article: 138029
Subject: dual processor PC for PPR - are they worth the extra cost?
From: Enes Erdin <eneserdin@gmail.com>
Date: Wed, 4 Feb 2009 05:28:16 -0800 (PST)
Links: << >>  << T >>  << A >>
Long time passed since the last post but I wonder your opinions about
this subject for today's technology. I am using a core2duo 1.8 GHz PC
and for my design P&R takes 40 + minutes and want to buy a new PC
powered by an AMD processor becasue of tis price but I can think some
other configuration if it is worth, related to your opinions about :

- dual core, quad core comparison
- cache for the processor camparison

Your suggestions will guide me.

Regards,

--enes

Article: 138030
Subject: Re: dual processor PC for PPR - are they worth the extra cost?
From: Enes Erdin <eneserdin@gmail.com>
Date: Wed, 4 Feb 2009 05:38:48 -0800 (PST)
Links: << >>  << T >>  << A >>
I thought it would be a continuatiton for
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/50a3d3356726c68d/

Thanks in advance,

--enes


Article: 138031
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Wed, 4 Feb 2009 05:42:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 4:45 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Tue, 3 Feb 2009 13:21:25 -0800 (PST), jleslie48 wrote:
> >Here's the simulation of the 16 character printout:
>
> >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> >everything looks to me ship-shape.
>
> >I'm gonna have to compare this simulation to a 15 character one.
>
> >anybody see anything?
>
> Yes.
>
> Jon, how do I put this politely....
>
> (1) you're not listening;
> (2) your debugging technique leaves something to be desired.
>
> I asked you whether you were leaving enough time for the serial
> line to settle at its idle condition before the first character
> goes out.  You haven't answered, but the answer, very obviously,
> ia "no, you're not".  Your serial line idles for only a few
> hundred nanoseconds before the first start bit goes out.
> Depending on what the FPGA was doing during configuration,
> that might or might not work downstream.  It's hopeless.
>
> So your design is immediately broken.  If it's broken, then
> small differences between two forms of brokenness will mask
> the real trouble.  Insisting on fixing one minor issue when
> so much else is so broken is just a recipe for wasting time.
>
> PLEASE, PLEASE fix the dreadful mess that is your data
> generator. Only when you have something whose behaviour
> is predictable and controllable can you hope to debug any
> real problems.
>
> I sent you a private email suggesting ways you might
> be able to get some useful support.  It may have fallen
> into your spamtrap, but whatever, I didn't get a response.
> Several of us have seen that you are going at this in
> a creative and generally intelligent, but badly flawed,
> way; so you've had loads of suggestions that a less
> thoughtful poster would not have received.  For heaven's
> sake take the higher-level advice too: SORT THE MESS OUT.
> You've now futzed around for about three quite long days
> and you still haven't got UART 101 working reliably.
> Surely you're smart enough to see that the right solution
> is to start again, properly?
>
> yours somewhat despairingly
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

Well, I cannot deny that I am floundering.

I don't see your private email in my inbox or spam filter.
I'm at jleslie48@yahoo.com or jon@jonathanleslie.com

~ I asked you whether you were leaving enough time for the serial
~ line to settle at its idle condition before the first character
~ goes out.  You haven't answered, but the answer, very obviously,
~ ia "no, you're not".  Your serial line idles for only a few
~ hundred nanoseconds before the first start bit goes out.
~ Depending on what the FPGA was doing during configuration,
~ that might or might not work downstream.  It's hopeless.

If I didn't answer then I apologize.  The answer is I don't understand
the question.  It appears to me from this screen shot:

http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap13_firstislast16.png

that my serial line ( rs232_tx_data) idles for 955ns based on the
whole system waiting for
uart_reset_buffer.  If that is not enough, then that was not made
clear to me. I had some feelings
that the issue lied somewhere with that, hence I supplied very careful
screen caps of the waveforms,
hoping someone would point out how to read them.  I have never worked
with waveforms/timing
diagrams before.

And while this might seem hopeless to you, I have no choice in the
matter.  I have no
funding at this time to bring on additional personnel and quite
frankly, prior to this
discussion, I wouldn't of even been qualified to hire someone; one of
my problems in
the past.  So to that level, this conversation has been productive for
me at least.

I am truly sorry my issues are so entry level, but we all must start
somewhere. Every programming
environment I've ever had to learn (and there have been many) has had
by page 3 demonstrated the
basic "hello world" program. I have been through many websites and
textbooks and for this environment,
it is very suspicious by its absence that the "hello world" program is
missing.

~ You've now futzed around for about three quite long days
~ and you still haven't got UART 101 working reliably.
~ Surely you're smart enough to see that the right solution
~ is to start again, properly?

Actually, I've been futzing around for 2 months and have "started
again"
4 times already.  Actually my associate has been futzing for almost
6,
and this version is his interpretation of how to program.  This
version,
warts and all, is the first is the first to at least send ANYTHING
out.

I think this messed up version is very close to working properly, and
to abandon it now would be to miss out on understanding something
important I am missing.  Effecting a fix properly I still feel is
important
before adding another variable to the equation (new code with new
issues)

That's the way I debug, understand what you have first, try and fix,
and then break it down to a streamlined scalable procedure.



Article: 138032
Subject: Re: rs232 uart: testbench vs real world, and the missing first letter.
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Wed, 04 Feb 2009 13:46:22 +0000
Links: << >>  << T >>  << A >>
On Tue, 3 Feb 2009 11:24:17 -0800 (PST), jleslie48 wrote:

>> I make the message string:
>>   constant project_name_stg      : string := "123456789a12345";
>>
>> aka, 15 characters, all is well.
>> I make it 16 characters:
>>   constant project_name_stg      : string := "123456789a123456";
>>
>> my output becomes:
>> 23456789a1234561
>>
>> were the 1 at the end is indeed the first character not the last.

No conceivable way this could be correlated with the fact
that your UART's FIFO buffer is 16 places deep, surely??? :-)
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 138033
Subject: Re: rs232 uart: testbench vs real world, and the missing first letter.
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Wed, 04 Feb 2009 14:04:31 +0000
Links: << >>  << T >>  << A >>
On Wed, 4 Feb 2009 05:42:01 -0800 (PST), jleslie48 wrote:

> my serial line ( rs232_tx_data) idles for 955ns based on the
>whole system waiting for
>uart_reset_buffer.  If that is not enough, then that was not made
>clear to me. 

It's nowhere near enough to make me feel safe.

Any real UART receiver - like the one in your PC - is 
quite likely to get messed-around by whatever happens
in your FPGA during startup.  So you MUST allow the line
to idle for at least one CHARACTER time before sending
anything; that way, the PC or whatever receiver will 
have a chance to sort itself out reliably before 
getting your data.  A character time at 115kBd is, 
by my reckoning, around 90 microseconds - around 
a hundred times more than you currently allow.

I'm not saying it will ALWAYS fail, but rather that
here is a goofy variable in the debugging that might
easily introduce nonsensical behaviour that would
throw you off the scent of more important issues.

>I had some feelings
>that the issue lied somewhere with that, 

I am very sure that you have more than just one issue.

> I have never worked with waveforms/timing diagrams before.

yeah.... powerful, useful tool, but takes a bit of 
getting used to.  

>And while this might seem hopeless to you

Did I say hopeless?  Yes, but not about YOU - 
rather, about a piece of code, I think.

> I have no choice in the matter.  I have no
>funding at this time to bring on additional personnel and quite
>frankly, prior to this
>discussion, I wouldn't of even been qualified to hire someone; one of
>my problems in the past. 

Fair enough.  Though I have to say that you're putting
yourself in a fairly scary position.

>I am truly sorry my issues are so entry level,
> but we all must start somewhere.

I know that very well.  It seems to me that
no beginner need ever apologize for asking
interesting questions.  However, one might
reasonably accuse you of biting off too much
at once.....

> Every programming
>environment I've ever had to learn (and there have been many) has had
>by page 3 demonstrated the
>basic "hello world" program. I have been through many websites and
>textbooks and for this environment,
>it is very suspicious by its absence that the "hello world" program is
>missing.

Hmmm.... I somewhat sympathise, but you might care to question
why people continue to pay us non-trivial amounts of money for
our very, very carefully designed training on exactly this kind
of stuff.  I am willing to bet a few beers that if you had
spent this week on our class, rather than banging your head
against a brick wall, you would be ready to move forward
as soon as you got back to the office.

Looking ahead a little: if you insist on regarding this as
"programming" you are fairly sure to end up in the mire.
Programming skills are good, useful, helpful; but hardware
design requires a very clear *structural* vision of what
you're trying to build, as well as a *procedural* one.

>I think this messed up version is very close to working properly, and
>to abandon it now would be to miss out on understanding something
>important I am missing.

OK.  One last push.  I'm on a couple of days' vacation so 
I will make a genuine effort to work out what you're doing
wrong.  Can't do very much more though, sorry.

>That's the way I debug, understand what you have first, try and fix,
>and then break it down to a streamlined scalable procedure.

Yes, but when you have given yourself something very wrong
indeed, the effort of understanding it may be a lot greater
than the understanding justifies.  Putting the same amount
of effort into understanding a couple of well-written
examples might pay much better dividends.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 138034
Subject: Re: xilinx platform usb cable linux troubles
From: luudee <rudolf.usselmann@gmail.com>
Date: Wed, 4 Feb 2009 06:15:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 7:27=A0pm, "h.e." <h...@thisisnovalidaddress.net> wrote:
>
> did you try the firmware version 1100? I had problems with older
> versions, too...

How do I do that ?  Sorry, I am not to familiar with the Xilinx USB
stuff ...

Thanks,
rudi

Article: 138035
Subject: Re: Choosing RAM for microblaze and connecting it.
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 4 Feb 2009 14:46:35 -0000
Links: << >>  << T >>  << A >>
Jan wrote:
> Dear all,
>
> I'm working on a small project where I need a microblaze with external
> memory.
>
> It needs to be cheep so I guess SDRAM is the right choice? I don't
> need much memory.
>
> My next problem is how to connect it to the FPGA so microblaze can use
> it. I can't seem to find any detailed documentation. Maybe one of you
> have done the trick before and know where to find the information.
>
> Thanks in advance!
>
> Regards
>   Jan

Jan,

Google.

microblaze schematic site:xilinx.com

HTH., Syms.



Article: 138036
Subject: Re: Why the second flip-flop in Virtex-6?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 04 Feb 2009 14:46:58 +0000
Links: << >>  << T >>  << A >>
On Tue, 3 Feb 2009 15:12:41 +0000 (UTC), jhallen@TheWorld.com (Joseph H Allen)
wrote:

>I'm surprised that the Spartan-6 integrated memory controller does not support
>DIMMs.  Also surprised that there are no integrated memory controllers in
>Virtex-6.
>
>Note the Virtex-6 Select-IO voltage range: only up to 2.5V!  2.5V is the
>new 5V...

Reading between the lines here...

At a guess the V6 I/O blocks are fast enough to support DDR memory quite well
without special support - and that way you have the flexibility to support any
configuration you need (modulo SSO limitations; the tools will handle those)

But the S6 would struggle without special support... which would explain why it
has blocks the V6 doesn't. It is targetted at lower cost apps where you rarely
need DIMMs. But at a guess you may be able to support DIMMs with some speed
limitations; maybe you can tap into the memory controllers for all except the
datapath.

- Brian


Article: 138037
Subject: Re: Why the second flip-flop in Virtex-6?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 04 Feb 2009 14:47:04 +0000
Links: << >>  << T >>  << A >>
On Tue, 3 Feb 2009 18:14:23 +0100, "Jan Bruns" <testzugang_janbruns@arcor.de>
wrote:

>
>"Joseph H Allen":
>> Benjamin Couillard  <benjamin.couillard@gmail.com> wrote:
>>>On 3 fév, 10:12, jhal...@TheWorld.com (Joseph H Allen) wrote:
>>>> I'm surprised that the Spartan-6 integrated memory controller does not support
>>>> DIMMs. Also surprised that there are no integrated memory controllers in
>>>> Virtex-6.
>>>>
>>>> Note the Virtex-6 Select-IO voltage range: only up to 2.5V! 2.5V is the
>>>> new 5V...
>>>
>>>3.3V is the new 5V you might say
>
>> No, 3.3V was the old new 5V.  The new new 5V is 2.5V.  Altera Straitx-IV
>> also does not support 3.3V I/O.
>
>Hm, ok, the old 5V-TTL logic devices pobably weren't compatible with
>tube-level logic.

Heh - maybe they were.

If you wanted a high current PSU in those days, it tended to be 6.3V AC.
Now if you multiply by sqrt(2), subtract a couple of diode drops, 10% for
regulation, 5% for line tolerance, a volt for ripple, and enough for a linear
regulator... you're about 5V.

- Brian

Article: 138038
Subject: REWARD $$$ Xilinx USB Platform Cable problems
From: luudee <rudolf.usselmann@gmail.com>
Date: Wed, 4 Feb 2009 07:05:08 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi All,

I need help, and am willing to pay for it. If you can
help me solve my problem, I will pay you. Name your
price, and see if you can help me:

Here is my problem:

I am running Fedora Core 7, x86_86, kernel 2.6.28.
I have libusb installed, and everything works fine with
ISE 10.1. However, I am forced to upgrade to 10.1 sp3.
And that's where everything breaks. I need for it to
work "normally" with libusb, so I can use impact and
chipscope. I can switch to 10.1 and it works, I go to sp3,
and it is broken. Yeah, I do have XIL_IMPACT_USE_LIBUSB
set.

If you think you can help, please email me privately:
rudolf.usselmann at gmail dot com

Time is of essence !

Thanks !
rudi


This is how impact fails:

impact -batch etc/download.cmd

[ ----- Deleted probing for parport ----- ]

 Using libusb.
Connecting to cable (Usb Port - USB21).
Checking cable driver.
File version of /tools/Xilinx_10.1_x86_64/ISE_sp3/bin/lin64/
xusbdfwu.hex = 1030.
File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1030.
 Using libusb.
 Max current requested during enumeration is 74 mA.
Type = 0x0004.
 Cable Type = 3, Revision = 0.
 Setting cable speed to 6 MHz.
Cable connection established.
Firmware version = 1028.
File version of /tools/Xilinx_10.1_x86_64/ISE_sp3/data/xusb_xlp.hex =
1303.
Firmware hex file version = 1303.
Downloading /tools/Xilinx_10.1_x86_64/ISE_sp3/data/xusb_xlp.hex.
Downloaded firmware version = 1303.
PLD file version = 0012h.
 PLD version = 0012h.
bulk tranfer failed, endpoint=02.
write count != nBytes(0), rc = 20000020.
write cmd failed 20000020.
control tranfer failed.
write cmdbuffer failed 20000020.
Error reading reference voltage level.
Elapsed time =      3 sec.
control tranfer failed.
write cmdbuffer failed 20000020.
Elapsed time =      3 sec.

Article: 138039
Subject: Re: REWARD $$$ Xilinx USB Platform Cable problems
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 4 Feb 2009 08:13:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 5:05=A0pm, luudee <rudolf.usselm...@gmail.com> wrote:
> Hi All,
>
> I need help, and am willing to pay for it. If you can
> help me solve my problem, I will pay you. Name your
> price, and see if you can help me:
>
> Here is my problem:
>
> I am running Fedora Core 7, x86_86, kernel 2.6.28.

solution 1:

get another cheap PC, install the required and working versions cable
drivers
there and connect over ethernet to your cable server PC

fighting with impact is pointless to absurd. it sometimes works.
thats all that can be said.

that sametimes usually isnt then when you need it most.

Antti
PS good luck getting your paid answer..:)
11.1 is soon to be released, so you will again fight
the linux drivers

a winxp PC cableserver box is cheaper solution




Article: 138040
Subject: Re: Spartan-6
From: Simon <google@gornall.net>
Date: Wed, 4 Feb 2009 08:15:45 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 8:33=A0pm, Eric Smith <e...@brouhaha.com> wrote:
> Simon <goo...@gornall.net> writes:
> > well, this is all very nice, but more importantly, when are they going
> > to actually start delivering these things, and how much will they
> > cost ?
>
> > I can't really believe they haven't *got* that information, so why the
> > staged release of info ?
>
> When was the last time that a semiconductor vendor gave you such
> information about a major new product release, and the information
> actually proved to be reasonably accurate?

Agreed, but then you take the price-estimate the vendor gave for the
last series, get the 1-off, 100-off, 1000-off price (at launch) from
your parts-source of choice, calculate the ratio and apply to the new
vendor price as an approximation :)

Simon

Article: 138041
Subject: Re: Spartan-6
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 4 Feb 2009 08:20:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 6:15=A0pm, Simon <goo...@gornall.net> wrote:
> On Feb 3, 8:33=A0pm, Eric Smith <e...@brouhaha.com> wrote:
>
> > Simon <goo...@gornall.net> writes:
> > > well, this is all very nice, but more importantly, when are they goin=
g
> > > to actually start delivering these things, and how much will they
> > > cost ?
>
> > > I can't really believe they haven't *got* that information, so why th=
e
> > > staged release of info ?
>
> > When was the last time that a semiconductor vendor gave you such
> > information about a major new product release, and the information
> > actually proved to be reasonably accurate?
>
> Agreed, but then you take the price-estimate the vendor gave for the
> last series, get the 1-off, 100-off, 1000-off price (at launch) from
> your parts-source of choice, calculate the ratio and apply to the new
> vendor price as an approximation :)
>
> Simon

Simon,

simple math approx
cheapest S3A qty one digikey price is 6.8$
from that i would derive 10k price to fall below 4$ (after price
battle negotations...)
if we assume some % price drop for S6
then we get what? 3$

So the price given by Xilinx (smallest S6 qty 10k =3D 3$) and publisched
by Peter Clarke may actually be accurate.

Antti









Article: 138042
Subject: Re: Implementation of Xilinx Aurora protocol with error correction
From: "S. Bernstein" <jiffylube@freenet.de>
Date: Wed, 4 Feb 2009 17:36:50 +0100
Links: << >>  << T >>  << A >>
"Nathan Bialke" <nathan@bialke.com> wrote:
>
>The route I've considered, but not implemented, for something
>approximating this is to use an Aurora-like protocol (with all K
>characters being triplicated) with Reed Solomon encoding being done on
>the data at the 8b/10b level (using 10 bit symbols). If you'd like
>more detail, feel free to contact me.

Hi Nathan,

thanks for your reply. I'd like to go into more details about your 
suggestion because it sounds very interesting. I'm familiar with 
Reed-Solomon encoding. So tell me, what's the point in triplicating all 
K-characters? Do you apply the RS on the 10 bit symbols, i.e. after the phy 
coding layer?

Regards,
Saul 



Article: 138043
Subject: Re: REWARD $$$ Xilinx USB Platform Cable problems
From: luudee <rudolf.usselmann@gmail.com>
Date: Wed, 4 Feb 2009 08:39:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 11:13=A0pm, Antti <Antti.Luk...@googlemail.com> wrote:
>
> solution 1:
>
> get another cheap PC, install the required and working versions cable
> drivers
> there and connect over ethernet to your cable server PC
>
> fighting with impact is pointless to absurd. it sometimes works.
> thats all that can be said.
>
> that sametimes usually isnt then when you need it most.
>
> Antti
> PS good luck getting your paid answer..:)
> 11.1 is soon to be released, so you will again fight
> the linux drivers
>
> a winxp PC cableserver box is cheaper solution


Hi Antti,

yes, I have been thinking of what you have suggested as
a "last resort". I figure give it a try and see if there
is somebody out there who might know how to fix this really
annoying problem ...

Regards,
rudi

Article: 138044
Subject: Antti-Brain issue 5 released
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 4 Feb 2009 09:01:27 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi

with less delay than last month
http://groups.google.com/group/antti-brain/files

but probably even less polished :(
well with monthly frequency, it has to be monthly released.. so it is
out.

i have received very little feedback so well.
the little, well i appreciate it :)

ah, there is also picture of 0.5mm BGA soldered on
PCB made without any special technologies, 2 layer no microvia
no super small track/space

Antti

Article: 138045
Subject: Re: REWARD $$$ Xilinx USB Platform Cable problems
From: Andy <andrewgschmidt@gmail.com>
Date: Wed, 4 Feb 2009 10:40:58 -0800 (PST)
Links: << >>  << T >>  << A >>
We have 5 Xilinx JTAG Cables on the same server working fine in our
lab (with iMpact and ChipScope).  From your error log it appears to be
a problem with firmware versions.  I also get the reference voltage
error when the board isn't on or the JTAG isn't connected to the
board.

I personally have avoided Xilinx's drivers and have been using:
  http://www.rmdir.de/~michael/xilinx/

We have both Version 1 and 2 USB JTAG cables along with our own custom
FTDI JTAG working with these drivers.  I would suggest taking a look
at Michael's driver.  I wouldn't recommend Windows, because I cannot,
in good conscience, ever recommend Windows.

- Andy

From rgaddi@technologyhighland.com Wed Feb 04 10:57:12 2009
Path: flpi142.ffdc.sbc.com!flph199.ffdc.sbc.com!prodigy.com!flph200.ffdc.sbc.com!prodigy.net!newshub.sdsu.edu!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.lmi.net!news.lmi.net.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 04 Feb 2009 12:57:08 -0600
Date: Wed, 4 Feb 2009 10:57:12 -0800
From: Rob Gaddi <rgaddi@technologyhighland.com>
Newsgroups: comp.arch.fpga
Subject: Re: Core interface protocol
Message-Id: <20090204105712.c659a0c8.rgaddi@technologyhighland.com>
References: <58397ef9-070d-4449-b218-b192cb7af61b@t39g2000prh.googlegroups.com>
Organization: Highland Technology, Inc.
X-Newsreader: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 32
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 66.117.134.49
X-Trace: sv3-B4xY16J4CLdjhPAMb7TGdJzb2i3KEVjVyqDgxOAjmV3pEruOjSlNfGf0w1BxvL1fgB8vUsz4LRUTY3O!N9s9595alT7J/hqt1Gn9ynyMBUsyQC+eCRdsyR9skFLzi0OYD6Bqrc7hEPto4EH5RvyaAVxgxTJL!41TufL67N3t4UeCvT7Q=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.39
Xref: prodigy.net comp.arch.fpga:151165
X-Received-Date: Wed, 04 Feb 2009 13:57:10 EST (flpi142.ffdc.sbc.com)

On Tue, 3 Feb 2009 22:33:13 -0800 (PST)
Manny <mloulah@hotmail.com> wrote:

> Hi,
> 
> In trying to conform to good design practices, I have been doubting
> lately my old ways. Until now, I've interfaced most of my cores to the
> external system using standard 2/4-phase asynchronous handshake
> protocols. Was wondering how good of a practice is this and whether
> there is a definitive handbook out there in the literature that
> tackles these issues. Don't want to sink into SoC bussing literature
> with overly complicated arbitration since most of the designs I work
> on are of the simple and tightly-coupled sort.
> 
> Would appreciate any pointers on this.
> 
> Regards,
> Manny

The last time I found myself trying to hook together just a few too
many cores to go with my usual ad hoc interfaces, I ultimately wound up
going over to a slightly stripped version of the WISHBONE SoC bus.
Once you collapse the STB and CYC signals down to the same signal
(which is the case for any single-master system that doesn't support
bursting), what's left is really just a naming convention for the
minimal set of signals you'd need to run.  STB is your request, ACK is
your acknowledge, and everything happens on the rising edge of the
system clock.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 138046
Subject: Re: Tabula - new kid on the FPGA block?
From: Svenn Are Bjerkem <svenn.bjerkem@googlemail.com>
Date: Wed, 4 Feb 2009 11:08:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 10:15=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> Nice to know I'm not the only curmudgeonly cynic out there :-)
>
> You're probably right. =A0Pessimists are rarely disappointed.

"Been there, done that" :-)

--
Svenn

Article: 138047
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: rickman <gnuarm@gmail.com>
Date: Wed, 4 Feb 2009 11:09:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 8:42 am, jleslie48 <j...@jonathanleslie.com> wrote:
> If I didn't answer then I apologize.  The answer is I don't understand
> the question.  It appears to me from this screen shot:
>
> http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> that my serial line ( rs232_tx_data) idles for 955ns based on the
> whole system waiting for
> uart_reset_buffer.  If that is not enough, then that was not made
> clear to me. I had some feelings
> that the issue lied somewhere with that, hence I supplied very careful
> screen caps of the waveforms,
> hoping someone would point out how to read them.  I have never worked
> with waveforms/timing
> diagrams before.

Let me jump back into the discussion here.  You seem to be getting
frustrated with the slowness of the learning curve.  Personally, I
found HDLs to be hard to learn, but I think this is made worse when
you are very used to designing software (as I have said before).  So
just take a deep breath and accept this fact.  Many have dealt with
this before and lived through it.  In fact, maybe there is something
good that can come of this.  At this point there are tons of good HDL
books out there, but I have not seen one specifically written for
people with strong software backgrounds.  Maybe we can work on a book
together.  You can be the guinea pig!  ;^)

I'm not totally clear on the current state of the discussion and some
of this seems to be focusing on details that may or may not be
important at this point.  Timing diagrams are very simple.  They are
just graphs of signal values as a function of time.  I am sure you get
that, but you are just not accustomed to debugging with them.  The
main reason for using them to debug hardware is because using the
alternative, code breakpoints and stepping, is rather tedious in HDL
since the information is presented serially as it happens.  A waveform
display gives you a lot of information in parallel with essentially
random access as you view it and figure out what is important or what
is working and what isn't.

I am not sure what is currently working and what isn't in your
design.  I will say that I think I have read that you are testing on
hardware and something there is not working, I guess the first
character is not being received by the other UART?  Is that UART also
in the FPGA or are you testing with a PC?  Before you worry about
testing hardware, I recommend that you run the simulation to show the
circuit is working there.  It is a hundred times easier to see what is
happening in simulation than in a test fixture.

Given that, I can't see anything in your simulation capture that shows
anything wrong.  It appears that sending data to the TX FIFO is
working.  The data sequence seems to be F23456789A123456 which is 16
chars, filling the FIFO as shown by the tx_buffer_full flag going
high.  After the first char is written to the FIFO I see an enable
pulse on uart_en_16_x_baud and one clock later I see the rs232_tx_data
go low.  This all seems to be working as expected.  I assume the baud
enable is 16x the actual bit rate, so the simulation time is not long
enough to watch the actual data emerge.  Have you checked this to see
that the simulation is transmitting the data correctly?  If the data
is being received by the FPGA UART, are all 16 chars received
correctly?

I am assuming that all of the above is true that the simulation shows
things working correctly and that your only problem shows when you
test on hardware.  That would make sense given Jonathan's suggestion
that you delay the start of your data transmission so that the
receiving UART can clear out any garbage from the startup sequence.
The startup delay may not be needed in simulation depending on the
details of the startup sequence.  This is one of the places where
simulation can differ from the real world.  In the real world there
are often uncontrolled variables such as arbitrary delays, that are
difficult to reproduce in simulation.

Do I understand the current situation?


> And while this might seem hopeless to you, I have no choice in the
> matter.  I have no
> funding at this time to bring on additional personnel and quite
> frankly, prior to this
> discussion, I wouldn't of even been qualified to hire someone; one of
> my problems in
> the past.  So to that level, this conversation has been productive for
> me at least.

The funding may be an issue.  Even if you don't have funds to bring a
consultant on board, you should get some training in this rather than
try to tough it out yourself.  I am sure you will eventually get it
done, but it will be a much more expensive process and take a lot more
time.


> I am truly sorry my issues are so entry level, but we all must start
> somewhere. Every programming
> environment I've ever had to learn (and there have been many) has had
> by page 3 demonstrated the
> basic "hello world" program. I have been through many websites and
> textbooks and for this environment,
> it is very suspicious by its absence that the "hello world" program is
> missing.

Don't sweat your inexperience.  Every one of us dealt with the same
problems starting out.  Usually the "hello world" program equivalent
is the "traffic light state machine" when designing HDLs.  Remember,
this is *not* a programming language, it is a hardware *description*
language.  When used for synthesis, you really need to get used to the
idea that you are NOT writing a program, you are describing hardware
to be synthesized.  Of course that is easy for me to say.  I started
out playing with JK FFs wired together on perf board powered by a 6
volt lantern battery.  :^)  Had 8080 CPU chips not been over $100 at
the time, I might be a total software junkie now instead.

Still, although your UART project may be a bit advanced for a
beginner, it is not absurd and I expect you will be able to complete
this shortly.  If you find the UART is too frustrating, you might want
to drop back to the traffic light program.


> ~ You've now futzed around for about three quite long days
> ~ and you still haven't got UART 101 working reliably.
> ~ Surely you're smart enough to see that the right solution
> ~ is to start again, properly?
>
> Actually, I've been futzing around for 2 months and have "started
> again"
> 4 times already.  Actually my associate has been futzing for almost
> 6,
> and this version is his interpretation of how to program.  This
> version,
> warts and all, is the first is the first to at least send ANYTHING
> out.

I think the above is an important data point.  2 months and 4 trials
should be a sign that this method is not working well.  The fact that
someone has been trying this stuff for 6 months shows that you likely
will not be ready to tackle a project for over a year!


> I think this messed up version is very close to working properly, and
> to abandon it now would be to miss out on understanding something
> important I am missing.  Effecting a fix properly I still feel is
> important
> before adding another variable to the equation (new code with new
> issues)

I don't want to sound like I am beating on you, but I think there are
problems of approach and expectations that are much bigger than the
technical issues.  My first HDL project happened because I took a
training class for Orcad schematic software that I was going to use
for an FPGA design (HDL was not so universally used at that time).
The last day of training taught VHDL.  I was so impressed with the
potential that I recommended that we use it on the project instead of
schematics.  As it turns out my greenness allowed me to miss the fact
that the Orcad HDL tools blew big chunks.  After spending a month or
maybe two working with the Orcad synthesis tool I realized that it was
never going to work and we bought the Xilinx tool (a third party tool
bundled with the Xilinx back end).  That worked much better.  Looking
back on my coding style, I realize that much of that code would likely
not pass muster by my current standards.  For example, I was using '-'
as a don't care condition.  I now know that this is not a good idea as
it is not universally supported.  I won't even think about the style I
used back then... actually some of my style from that first project
has served me well, but you get the idea.  Your first project will
likely not be anything that you are proud of a year later.


> That's the way I debug, understand what you have first, try and fix,
> and then break it down to a streamlined scalable procedure.

That is fine for debugging, but you are primarily in a learning mode.
That works much better when you take bite sized pieces and learn a bit
at a time rather than to try to get a much more complex effort done
that involves learning on many different levels.

I think that when you complete the "hello world" example, you will
still have a long way to go before you are ready to try a project.
The fact that waveform displays are still new and alien to you is a
*very* good indicator that you are still in the elementary school of
HDL design.

The more I think about it, the more I like the idea of writing a
book.  I don't currently have any design work, maybe I should take
that on as a project.

Rick

Article: 138048
Subject: Re: Sixteen serial ports ?
From: rickman <gnuarm@gmail.com>
Date: Wed, 4 Feb 2009 11:40:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 1:32=A0am, Bob Smith <use...@linuxtoys.org> wrote:
> Hi,
>
> I would like to use a Spartan 3 100K FPGA to implement 16
> serial ports. =A0The ports will be fairly simple: 1200 to
> 115200 baud, Tx, Rx, and two flow control lines per port.
>
> I already have a working serial port and could make sixteen
> instances of it. =A0This would chew up a lot of the FPGA.
>
> Is there a better way to build sixteen serial ports?
>
> Would it make sense to build one serial port and try to
> time division multiplex it to the sixteen sets of inputs,
> perhaps keeping all state information in RAM? =A0Is this a
> feasible or reasonable approach?

When you say 16 serial ports will chew up a lot of the FPGA, have you
measured the size of a simple UART?  If you need a complex UART with
FIFOs and handshake controls, I doubt that you will be able to save
much by somehow combining them.  But if you can use a simple UART with
just data in each direction and just a holding register, I suspect
even 16 of these will not be a big design.  If it is, you can build a
state machine that uses the LUTs as distributed RAM to emulate 16
registers and end up with a pretty optimized design.

I just think this will be more work than it is worth.  A simple UART
should be on the order of 50 LUTs (I'm estimating here) so even x16
that would only be 800 of almost 2000 LUTs... maybe that *is* a lot.
A sized optimized N duplicated UART might be an interesting design.

Rick

Article: 138049
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 4 Feb 2009 11:44:23 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 4, 9:09=A0pm, rickman <gnu...@gmail.com> wrote:
> On Feb 4, 8:42 am, jleslie48 <j...@jonathanleslie.com> wrote:
>
[snip]
> The more I think about it, the more I like the idea of writing a
> book. =A0I don't currently have any design work, maybe I should take
> that on as a project.
>
> Rick

to OP: general rule for UART design
after power on, and full system init that is UART mode setup, etc uart
hardware init complete
make

sleep( 1 second);

just wait 1 second before sending anything out the uart.

i have also troubleshooted FPGA system that failed to send data on
uart TX,
well they actually worked, but during powerup the TX maybe active,
those
forcing BREAK condition, and only heaven know how much recovery
after that may be required before PC will accept UART data.

it is possible that FPGA sends 100 chars, and PC receives say 8
if the break was removed to quickly and the uart didnt sync properly
at PC side.

the problem is hardly ever there where you look first :)

to Rick: i also have/have had plans of writing various stuff(books)

one of them would be titled "art of abstract problem solving"..

missing uart print is one good example where this art shoud be
applied :)

Antti
























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