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
2019JanFebMar2019

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 127750

Article: 127750
Subject: Re: What does this do ?
From: kays_f <kays_f@yahoo.com>
Date: Mon, 7 Jan 2008 00:49:26 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

> Hi,
> just two guesses:
> 1.) there's a port named std in the entity.

The "std" can also be a constant defined somewhere in the design file
or in "a package", also be careful about it too.

Regards,

Enes

Article: 127751
Subject: Re: Vendors of FPGA's
From: "T.Hansen" <honninghuset@hotmail.com>
Date: Mon, 7 Jan 2008 10:48:27 +0100
Links: << >>  << T >>  << A >>
Thank you all for your replies. It helped me finding the right solution.

Best Regards
Hansen

"austin" <austin@xilinx.com> wrote in message 
news:fllicq$l761@cnn.xsj.xilinx.com...
> Hansen,
>
> They order from a distributor.
>
> Or, they go to the manufacturer's website, and order online through
> their "store" (which actually takes you to a distributor).
>
> Austin 



Article: 127752
Subject: Processor in CPLD
From: "Rgr" <rgrworking@hotmail.com>
Date: Mon, 7 Jan 2008 11:09:25 +0100
Links: << >>  << T >>  << A >>
Hi.

I would like to hear your opinion on the possibility of implementing a 
processor in a CPLD?
The functionality does not have to be greater than the old 8051 CPU, but I 
would like the flexibility and the possibility of adding additional logic to 
my design.

Has someone worked on this issue, or have an opinion on how to complete this 
task?

Looking forward to your replies
Best Regards 



Article: 127753
Subject: Re: Processor in CPLD
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Mon, 7 Jan 2008 10:11:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rgr <rgrworking@hotmail.com> wrote:
> Hi.

> I would like to hear your opinion on the possibility of implementing a 
> processor in a CPLD?
> The functionality does not have to be greater than the old 8051 CPU, but I 
> would like the flexibility and the possibility of adding additional
> logic to  my design.

> Has someone worked on this issue, or have an opinion on how to 
> complete this task?

Look at
http://www.xilinx.com/products/ipcenter/picoblaze-CR2.htm

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 127754
Subject: Frame Transmission using Ethernet Lite
From: Surya <aswingopalan@gmail.com>
Date: Mon, 7 Jan 2008 02:50:17 -0800 (PST)
Links: << >>  << T >>  << A >>

Hello,

I am trying to send one single ethernet frame using Ethernet lite core
in the XUP2VP board from Digilent Inc. I am unable to do so. I am
trying to capture the sent packet using Wireshark. However, i am not
receiving any packet. But if i repeat the send functional call in a
for loop from 46 bytes to 1500 bytes, the frames are received in the
packet capture utility.

i am using the XEmacLite_Send function call to send an ethernet frame.

Is there an issue which i need to look at while sending a single
frame? kindly advice.

Thanks in advance!

Regards,
G Aswin.

Article: 127755
Subject: Re: Camera connection on XUPV2P
From: "MJ Pearson" <mjp500@york.ac.uk>
Date: Mon, 07 Jan 2008 04:50:46 -0600
Links: << >>  << T >>  << A >>

>>
>> Hi, thanks for the replies,
>>
>> I thought my PCB might be the problem. I didn't perform any impedance
>> matching or termination. I'm "tapping-off" the signals between the
camera
>> and framegrabber. So i have a straight through connection - camera to
>> framegrabber and then "tap-off" the LVDS data-signals and clock and
send
>> these into the DS90CR288A. This way I can setup and control the camera
>> using the camera software on PC, and just perform data processing on
>> FPGA.
>>
>
>Tapping into 7 * 66 MHz = 462 Mbps LVDS lines needs to be done
>carefully
>to avoid signal integrity problems at the receiver.  However if your
>LVAL and DVAL signals look correct, you may have lucked out...
>
>> I wasn't sure I needed to terminate the lines, as this would be
performed
>> further up the line - at the framegrabber end. The pixel clock from
the
>> camera should be 66MHz (I think), so thought I was on the right lines
with
>> a 16ns period. The chip however is the 85Mhz version. Is this a
maximum?
>> I'm not sure what the clock output of the chip should be - 85Mhz or
>> 66MHz!?
>>
>
>Channel-Link receivers have a wide frequency range of about 20 MHz
>minimum to the specified maximum (66 or 85 MHz).  66 MHz should
>work fine.
>
>> I can see data on the output of the chip, LVAL and DVAL signals are
>> correct, not sure about the clock. As I say, the output voltage swing
is
>> about 600mV, and looks sinusoidal in shape on the scope - Sorry for
the
>> description! The distance between the chip and the connector is about
>> 10mm. Do i need termination resistors across the differential lines in
my
>> case?
>
>You may be OK with the 10mm stubs.  Definitely don't terminate them
>if there is already termination at the framegrabber.  Also if you
>still get a proper picture at the framegrabber, you probably
>have reasonable signal integrity.  With your scope it would be
>hard to look at this...
>
>I'm going to guess that the clock is correct, too, but that your
>scope is bandwidth limiting the signal to form the sine wave you
>see.  What is the input bandwidth of your scope and probe?  Did
>you try to implement a simple T flip-flop in the FPGA to see if
>the clock is getting into the chip OK?
>
>Regards,
>Gabor
>

Thanks again Gabor..

The system does seem to be working ok. I get the correct image at the
frame-grabber end, and all the signals do seem to be correct. The scope
I'm using says 60MHz on it, I guess this the bandwidth - in which I guess
it will struggle to observe the higher frequency signals??

I implemented a T-flip flop, and got a decent signal at half the input
frequncy across an LED on the board, so it looks like everything is ok -
probably just my VHDL letting me down! The LVAL, DVAL signals are working
as expected aswell - used the LEDs to observe these. 

Just as an aside - when I increase the precision of the camera's output 8
bit to 16 bit, the camera sends the data in two "packets". For one LVAL
pulse, the are two DVAL pulses. I think this maybe camera specific, but I
think the data may be being sent low bits (0-7) with the first DVAL pulse,
followed by high bits with the second. My camera is always is in
camera-link BASE mode. I've scoped all the data channels from the chip,
and the higher outputs are not used - apart from RxOut 27. Am I right
thinking that in base mode the data should be re-created as:

Bit(0) - RxOut 0
Bit(1) - RxOut 1
Bit(2) - RxOut 2
Bit(3) - RxOut 3
Bit(4) - RxOut 4
Bit(5) - RxOut 6
Bit(6) - RxOut 27
Bit(7) - RxOut 5

Just wondered if anyone else had any experience with 16 bit data in base
mode?

Regards

Marc.

Article: 127756
Subject: Re: MPMC On EDK
From: ratemonotonic <niladri1979@gmail.com>
Date: Mon, 7 Jan 2008 03:14:44 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 6, 9:25 pm, Daniel Koethe <dkoe...@nospam-web.de> wrote:
> ratemonotonic schrieb:
>
>
>
> > On 6 Jan, 16:44, Daniel Koethe <dkoe...@nospam-web.de> wrote:
> >> The MPMC DDR-Interface is based on the MIG-Memory Controller. Download
> >> athttp://www.xilinx.com/products/ipcenter/MIG.htmthe"User Guide"
> >> (ug086.pdf). See page 331/332: Generic Memory Interface Guidelines.
>
> >> Daniel
>
> >> ratemonotonic schrieb:
>
> >>> Hi All ,
> >>> I am trying to interface microblaze with a Micron DDR SDRAM
> >>> (MT46V16M16FG-75 16Mx16) using MPMC from the IP catalogue. As I am
> >>> running on Spartan 3 FPGA I need to connect port lines - DDR_DQS_DIV_O
> >>> and DDR_DQS_DIV_I , else I get errors , it also states that these
> >>> should be connected in for spartan 3.
> >>> The problem is that there is not much documentation about these port
> >>> lines in the MPMC data sheet. Has anyone used this? does any one know
> >>> how to connect these lines up?
> >>> thanks in advance
> >>> BR
> >>> rate
>
> > Hi Daniel ,
>
> > Thanks for the links the doc looks good and I am going through it now.
> > Is the MPMC suitable to interface with asynchronous DDR SDRAMS? i.e.
> > the reference board I am using has Micron MT46V16M16FG-75 16Mx16 part
> > which takes min 75mhz clock. the microblaze on the board is running at
> > 50 Mhz, but the board has 75Mhz clock. In the original design an OPB
> > DDR SBRAM controller was used in which there was seperate control for
> > the DDR clock inputs , but MPMC only seems to take the system clock as
> > an input which is my case is 50 Mhz. How do I produce an 75 Mhz DDR
> > clock from MPMC?
>
> The MPMC can not produce a 75Mhz clock from a 50 Mhz source. But the
> MPMC supports 1:2 System/PIM clock and memory clock.
>
> See at page 50 of Datasheet MPMC (DS643) near "<PIM>_Clk".
>
> For example you have a 50Mhz source clock, use clk0 (system clock) and
> clk2x output of a DCM to produce the 100Mhz memory clock. Do not forget
> to connect clk0 and clkfb to assure zero phase offset.
>
>
>
> > Thanks very much ,
> > BR
> > Rate

Hi Daniel,
Thanks a lot !  I sort of see light at the end of the tunnel now with
your suggestion! I will let you know when I have tested the setup!

Thanks
rate

Article: 127757
Subject: Re: DDR SDRAM demo for Spartan-3E starter kit?
From: quark.flavour@gmail.com
Date: Mon, 7 Jan 2008 04:37:24 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 6, 1:59=A0pm, j...@capsec.org wrote:
> I'd be happy if this could become a friendly cross vendor SoC
> evironment, so please let me know if you're running into
> difficulties.I understand that the absence of any documentation
> for the build environment is a major hurdle :(

Of course, I've tried to load the firmware and it runs smoothly
except for a long term error (ld0) that, as far as I've seen, occurrs
in the first few 5 - 8 read/write operations. I still have to dig into
the
problem, if I'll find something I'll report to you immediately. Maybe
it's
something about the DCM, a difference between the boards.
BTW the absence of documentation is not a problem at all since
I'm working on memory interface and your code is very good
and readable.

> Hearing about success stories would be nice too :)

Well, I'll do my best but I'm just learning, and I cannot say I've
ever done
something worthy as far, just experiments!

> I'm currently evaluating how to proceed -- I think a soft loaded TLB
> architecture is the way to go. But I need to understand precisely how
> the caches work inside the LM32...

Keep up the good work, I'll keep an eye on the progress of the
project.

Andrew

Article: 127758
Subject: Re: Processor in CPLD
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 07 Jan 2008 06:07:21 -0800
Links: << >>  << T >>  << A >>
Rgr wrote:
> Hi.
> 
> I would like to hear your opinion on the possibility of implementing a 
> processor in a CPLD?
> The functionality does not have to be greater than the old 8051 CPU, but I 
> would like the flexibility and the possibility of adding additional logic to 
> my design.
> 
> Has someone worked on this issue, or have an opinion on how to complete this 
> task?
> 
> Looking forward to your replies
> Best Regards 

The Xilinx PicoBlaze or the open-source Mico-8 from Lattice should both 
be achievable in a CPLD but most CPLDs don't have memory.

While it's more of a simple FPGA than an ASIC, the Altera Max-II series 
of "CPLDs" has some user Flash memory available on-chip.  Most CPLDs 
will require external memory.

- John_H

Article: 127759
Subject: Re: MicroBlaze floating point precision issues
From: JD Newcomb <the.jd.in.space@gmail.com>
Date: Mon, 7 Jan 2008 07:55:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 7, 2:13 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> JD Newcomb wrote:
> > float test = 22;   // for example
> > printf("test = 0x%08x\r\n",test);    // prints   "test = 0x40360000"
> > printf("test = %d\r\n",test);    // prints    "test = 1077280768"
> > printf("test = %f\r\n",test);     // prints    "test = 22.000000" or
> > some precision
> > 22 in single-point floating point (hex) is 0x41B00000, and in double-
> > precision is 0x4036000000000000. So, truncate the double-precision
> > value and you have what's printed to the screen. I'm completely
> > baffled. Am I missing something? A gcc flag? How is this even possible
> > for a single-precision instruction set?
>
> That is C.
>
> C always converts (float) to (double) before passing it to a
> varargs function.  %f expects a double, not a float, as it will
> always be converted before the call.
>
> try:
> printf("test = 0x%08x\r\n",*(int*)&test);
>
> (assumes sizeof(float)==sizeof(int), but you were already
> assuming that.)
>
> -- glen

Thanks Arlett. The Xilinx xil_printf() doesn't handle floats, so I was
forced to use hex. The 08x will force %x to only print 32 bits anyway,
which is what I want.

Glen, this conversion on a single-precision processor like the
MicroBlaze is emulated to be double-precision, correct? This seems, to
me, the only way that it can be done on such a processor. But I am not
100% sure about that. And floats and ints on the MIcroBlaze are the
same size (4 bytes). So, the value in memory might be correct, though
the value printed is not. Yay for unnecessary conversions.

Your test proved correct. I've also used a direct read of the memory
address in a similar way using the xio.h functions, which prints the
same correct value. Thanks for your help, guys.

Article: 127760
Subject: Re: Processor in CPLD
From: "Rgr" <rgrworking@hotmail.com>
Date: Mon, 7 Jan 2008 17:12:32 +0100
Links: << >>  << T >>  << A >>
"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:lt6dncs0fYiIrx_anZ2dnUVZ_j-dnZ2d@comcast.com...
> Rgr wrote:
>> Hi.
>>
>> I would like to hear your opinion on the possibility of implementing a 
>> processor in a CPLD?
>> The functionality does not have to be greater than the old 8051 CPU, but 
>> I would like the flexibility and the possibility of adding additional 
>> logic to my design.
>>
>> Has someone worked on this issue, or have an opinion on how to complete 
>> this task?
>>
>> Looking forward to your replies
>> Best Regards
>
> The Xilinx PicoBlaze or the open-source Mico-8 from Lattice should both be 
> achievable in a CPLD but most CPLDs don't have memory.
>
> While it's more of a simple FPGA than an ASIC, the Altera Max-II series of 
> "CPLDs" has some user Flash memory available on-chip.  Most CPLDs will 
> require external memory.
>
> - John_H

Thank you both for your very useful replies.
I can see the benefits in utilizing the Max-II series, but have they made a 
soft-core processor usable for these CPLD's? Like the PicoBlaze?

Best Regards 



Article: 127761
Subject: Re: question on AND
From: Andy <jonesandy@comcast.net>
Date: Mon, 7 Jan 2008 08:16:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 5, 9:56 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
> On Jan 5, 7:42 pm, "pdudl...@comcast.net" <pdudl...@comcast.net>
> wrote:
>
>
>
> > FPGA wrote:
> > > On Jan 5, 12:46 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> > >> "FPGA" <FPGA.unkn...@gmail.com> wrote in message
>
> > >>news:81b075e5-8ab2-4c8d-abc1-4b65b351b4a2@21g2000hsj.googlegroups.com...
> > >> On Jan 4, 3:17 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
>
> > >>> FPGA wrote:
> > >>>> I have 2 inputs
> > >>>> x : unsigned
> > >>>> bw : integer
> > >>>> when x>bw I want to check if x(x'length downto bw) = "1111111......"
> > >>>> How do i write this in VHDL since my length of x is unknown
> > >>> A vector of unknown length could be
> > >>> an entity port or a subprogram parameter.
> > >>> These are usually handled using
> > >>> the array attributes 'length or 'range.
> > >>> and a for loop like this:
> > >>> for i in x'range loop
> > >>> result := some_function(result, x(i));
> > >>> end loop;
> > >>> -- Mike Treseler
> > >> I actually want to AND all the bits of the x vector whole length is
> > >> unknown. I want to check if all the bits of the vector x are
> > >> "1111...." . How would I do it, since the length is unknown. I want to
> > >> check is x(x'length-1) AND x(x'length-2) AND x(x'length-3) AND ....
> > >> x(0) = '1' -- which checks if all bits of the input are one.
>
> > >> All_Bits_Equal_1 <= '1' when (x = (x'range => '1')) else '0';
>
> > >> KJ- Hide quoted text -
>
> > >> - Show quoted text -
>
> > > Thank you very much KJ.
>
> > Also there is and_reduce() and or_reduce() in misc library.- Hide quoted text -
>
> > - Show quoted text -
>
> Thank you so much. The help provided by ppl like you immensely helps
> beginners like us.

Since X is already unsigned, comparisons with integer are allowed,
which means you could do something like:

if (not x) = 0 then
...

I don't know if and_reduce works on unsigned, so you may have to cast
to slv.

Andy

Article: 127762
Subject: Re: Processor in CPLD
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 7 Jan 2008 08:34:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 7, 8:12=A0am, "Rgr" <rgrwork...@hotmail.com> wrote:
>
> Thank you both for your very useful replies.
> I can see the benefits in utilizing the Max-II series, but have they made =
a
> soft-core processor usable for these CPLD's? Like the PicoBlaze?
>
> Best Regards

The PicoBlaze is intended for a Xilinx target.  The design uses Xilinx
primitives that may not map over to an Altera design.  The Mico-8 is
open source and does not use vendor-specific primitives.

CPLDs are typically not well suited for processor instantiation so
commonly you'll only see them in FPGAs.  It's because the Max-II parts
are more like early FPGAs that the fit might be reasonable.

Have you considered a tiny FPGA rather than a CPLD?  Having embedded
RAM can really help out.  If you want to access more code than would
conveniently fit in the on-board RAM, you can use the same SPI flash
that programs the FPGA to store additional user flash that you access
through an SPI interface.  Perhaps the additional flexibility from an
FPGA (versus CPLD) is worth considering.

- John_H

Article: 127763
Subject: Re: Ethernet on recent FPGAs
From: Rich Seifert <usenet@richseifert.com.invalid>
Date: Mon, 07 Jan 2008 08:35:06 -0800
Links: << >>  << T >>  << A >>
In article <B_KdnWf0IICN1hzanZ2dnUVZ_t6onZ2d@comcast.com>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> John McCaskill wrote:
> 
> > While I agree that the MAC ID space is so large that the chance of a
> > collision for a random address is very low, I do not agree with that
> > statement.  Buying a range of unique addresses is cheap and easy, and
> > no administrative hassle is involved.
> 
> There is a story that in the beginnings of ethernet using random 48 bit
> MAC addresses was considered, but rejected because of the (small)
> probability of two accidentally choosing the same address.
> 
> As I understand it, in the current system there have been devices
> produced that accidentally had the same address.  As the current system
> involves humans, such as programming ROMs and installing them in cards,
> there is a relatively high probability of accidents.
> 
> Choosing a random 46 bit number with the local administration bit
> on and the multicast bit off might not be so bad.
> 

We *did* consider using randomly-chosen addresses, but in a 64-bit 
address space; the probability of a clash in a 48-bit space was 
considered too high. I wrote a paper on the subject back in 1979-80, 
which is probably lost to history.

Although properly-implemented random addresses would have worked, we 
chose the administered-vendor-space 48-bit scheme of today as being more 
"politically palatable"; I am sure we would have been hammered even 
worse about letting randomness control network addressing than we were 
about letting randomness control the backoff algorithm.


--
Rich Seifert              Networks and Communications Consulting
                          21885 Bear Creek Way
(408) 395-5700            Los Gatos, CA 95033
(408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Article: 127764
Subject: Re: Processor in CPLD
From: Jecel <jecel@merlintec.com>
Date: Mon, 7 Jan 2008 08:43:34 -0800 (PST)
Links: << >>  << T >>  << A >>
This one is specially designed for small CPLDs:

http://www.opencores.org/projects.cgi/web/mcpu/overview

You will need an external memory, however. And note that it is far
simpler and more limited than a 8051.

-- Jecel

Article: 127765
Subject: Re: Processor in CPLD
From: Kris Vorwerk <kris.vorwerk@gmail.com>
Date: Mon, 7 Jan 2008 09:47:27 -0800 (PST)
Links: << >>  << T >>  << A >>
> I would like to hear your opinion on the possibility of implementing a
> processor in a CPLD?


As an alternative to CPLDs, have you considered Actel's Igloo FPGAs?
They're small-to-medium-sized FPGAs with a very low power footprint
(and you can use an ARM Cortex M1 processor on it).

http://www.actel.com/products/igloo/

K.

Article: 127766
Subject: Re: Processor in CPLD
From: Herbert Kleebauer <klee@unibwm.de>
Date: Mon, 07 Jan 2008 20:10:15 +0100
Links: << >>  << T >>  << A >>
Rgr wrote:
 
> I would like to hear your opinion on the possibility of implementing a
> processor in a CPLD?
> The functionality does not have to be greater than the old 8051 CPU, but I
> would like the flexibility and the possibility of adding additional logic to
> my design.
> 
> Has someone worked on this issue, or have an opinion on how to complete this
> task?

If you have at least 65 flip flops and a few hundred gates available on
your CPLD you can try:

ftp://137.193.64.130/pub/mproz/mproz3_e.pdf

Article: 127767
Subject: Re: Ethernet on recent FPGAs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 07 Jan 2008 12:26:05 -0800
Links: << >>  << T >>  << A >>
Rich Seifert wrote:

(snip)

> We *did* consider using randomly-chosen addresses, but in a 64-bit 
> address space; the probability of a clash in a 48-bit space was 
> considered too high. I wrote a paper on the subject back in 1979-80, 
> which is probably lost to history.

Higher than the actual clash rate on the current system?

> Although properly-implemented random addresses would have worked, we 
> chose the administered-vendor-space 48-bit scheme of today as being more 
> "politically palatable"; I am sure we would have been hammered even 
> worse about letting randomness control network addressing than we were 
> about letting randomness control the backoff algorithm.

I have heard stories about NICs produced with the same address,
most likely in the same batch with a high probability of being
installed on the same net.

We once had a Sun system that the local computer hardware people
sent back to Sun to be fixed.  The rule at the time was that one
should remove the ROM (or battery backed RAM) before sending it
in.  In this case, it was reinstalled backwards destroying the
stored address.  Losing the stored address from battery backed
RAM can't be that uncommon.  (The battery life tends to be
less than the processor life.)

Also, I once knew a net with a device with address 00:00:00:00:00:00.
As there was only one, it was decided to leave it alone.

-- glen


Article: 127768
Subject: Re: MicroBlaze floating point precision issues
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 07 Jan 2008 12:32:27 -0800
Links: << >>  << T >>  << A >>
JD Newcomb wrote:

(I wrote)

>>try:
>>printf("test = 0x%08x\r\n",*(int*)&test);
(snip)

> Glen, this conversion on a single-precision processor like the
> MicroBlaze is emulated to be double-precision, correct? This seems, to
> me, the only way that it can be done on such a processor. But I am not
> 100% sure about that. And floats and ints on the MIcroBlaze are the
> same size (4 bytes). So, the value in memory might be correct, though
> the value printed is not. Yay for unnecessary conversions.

Before ANSI C, K&R C did everything in double precision, except that
it had the ability to store and fetch from single precision (float)
variables.  ANSI C added float constants, and the ability to pass
them to non-varargs routines with a prototype in scope.  Routines
like printf always get a double.  For most people, the extra
overhead wasn't that big.

> Your test proved correct. I've also used a direct read of the memory
> address in a similar way using the xio.h functions, which prints the
> same correct value. Thanks for your help, guys.

-- glen


Article: 127769
Subject: Re: Camera connection on XUPV2P
From: Gabor <gabor@alacron.com>
Date: Mon, 7 Jan 2008 13:22:04 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 7, 5:50 am, "MJ Pearson" <mjp...@york.ac.uk> wrote:
> >> Hi, thanks for the replies,
>
> >> I thought my PCB might be the problem. I didn't perform any impedance
> >> matching or termination. I'm "tapping-off" the signals between the
> camera
> >> and framegrabber. So i have a straight through connection - camera to
> >> framegrabber and then "tap-off" the LVDS data-signals and clock and
> send
> >> these into the DS90CR288A. This way I can setup and control the camera
> >> using the camera software on PC, and just perform data processing on
> >> FPGA.
>
> >Tapping into 7 * 66 MHz = 462 Mbps LVDS lines needs to be done
> >carefully
> >to avoid signal integrity problems at the receiver.  However if your
> >LVAL and DVAL signals look correct, you may have lucked out...
>
> >> I wasn't sure I needed to terminate the lines, as this would be
> performed
> >> further up the line - at the framegrabber end. The pixel clock from
> the
> >> camera should be 66MHz (I think), so thought I was on the right lines
> with
> >> a 16ns period. The chip however is the 85Mhz version. Is this a
> maximum?
> >> I'm not sure what the clock output of the chip should be - 85Mhz or
> >> 66MHz!?
>
> >Channel-Link receivers have a wide frequency range of about 20 MHz
> >minimum to the specified maximum (66 or 85 MHz).  66 MHz should
> >work fine.
>
> >> I can see data on the output of the chip, LVAL and DVAL signals are
> >> correct, not sure about the clock. As I say, the output voltage swing
> is
> >> about 600mV, and looks sinusoidal in shape on the scope - Sorry for
> the
> >> description! The distance between the chip and the connector is about
> >> 10mm. Do i need termination resistors across the differential lines in
> my
> >> case?
>
> >You may be OK with the 10mm stubs.  Definitely don't terminate them
> >if there is already termination at the framegrabber.  Also if you
> >still get a proper picture at the framegrabber, you probably
> >have reasonable signal integrity.  With your scope it would be
> >hard to look at this...
>
> >I'm going to guess that the clock is correct, too, but that your
> >scope is bandwidth limiting the signal to form the sine wave you
> >see.  What is the input bandwidth of your scope and probe?  Did
> >you try to implement a simple T flip-flop in the FPGA to see if
> >the clock is getting into the chip OK?
>
> >Regards,
> >Gabor
>
> Thanks again Gabor..
>
> The system does seem to be working ok. I get the correct image at the
> frame-grabber end, and all the signals do seem to be correct. The scope
> I'm using says 60MHz on it, I guess this the bandwidth - in which I guess
> it will struggle to observe the higher frequency signals??
>
> I implemented a T-flip flop, and got a decent signal at half the input
> frequncy across an LED on the board, so it looks like everything is ok -
> probably just my VHDL letting me down! The LVAL, DVAL signals are working
> as expected aswell - used the LEDs to observe these.
>
> Just as an aside - when I increase the precision of the camera's output 8
> bit to 16 bit, the camera sends the data in two "packets". For one LVAL
> pulse, the are two DVAL pulses. I think this maybe camera specific, but I
> think the data may be being sent low bits (0-7) with the first DVAL pulse,
> followed by high bits with the second. My camera is always is in
> camera-link BASE mode. I've scoped all the data channels from the chip,
> and the higher outputs are not used - apart from RxOut 27. Am I right
> thinking that in base mode the data should be re-created as:
>
> Bit(0) - RxOut 0
> Bit(1) - RxOut 1
> Bit(2) - RxOut 2
> Bit(3) - RxOut 3
> Bit(4) - RxOut 4
> Bit(5) - RxOut 6
> Bit(6) - RxOut 27
> Bit(7) - RxOut 5
>
> Just wondered if anyone else had any experience with 16 bit data in base
> mode?
>
> Regards
>
> Marc.

The bit assignments are all in the Camera Link Specification:

http://www.alacron.com/downloads/vncl98076xz/CameraLinkSPEC.pdf

Most Camera Link cameras use two 8-bit "ports" A & B to output
16-bits on each clock.  I'm not familiar with any cameras that
use DVAL as a pixel framing signal.  Base Camera Link supports
up to 24 bits of data per clock.

Regards,
Gabor

Article: 127770
Subject: Re: Ethernet on recent FPGAs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 07 Jan 2008 14:34:36 -0800
Links: << >>  << T >>  << A >>
Nico Coesel wrote:
(snip)

> Yes and no. Like others already pointed out, devices need a serial
> number anyway. Not just for administration but also to keep track of
> devices. So having a fixed number (MAC address) assigned to unit xyz
> generally saves a lot of trouble.

As the subject is FPGAs, I believe it isn't hard to change data in
a synthesized ROM after the bit file has been generated.  That should
be pretty convenient for generating the packet.  Getting the IP
address is a little harder.

> Besides, if you are going to generate random MAC addresses you may get
> intermittant errors because fixed MAC addresses are expected. Those
> kind of errors are the last you want on a network.

Not so much network errors as administration problems.  It is harder
to track down devices with variable MAC addresses.

-- glen


Article: 127771
Subject: Re: Xilinx MIG onm Solaris
From: Michael Laajanen <michael_laajanen@yahoo.com>
Date: Tue, 08 Jan 2008 00:06:01 +0100
Links: << >>  << T >>  << A >>
Hi,

John Schmitz wrote:
> Correct, Linux and Windows only.  The workaround is to run the MIG tool on 
> Linux or Windows and transfer the output files over to the Solaris machine 
> for integration.
> 
> "Michael Laajanen" <michael_laajanen@yahoo.com> wrote in message 
> news:5ud26iF1hgf6pU1@mid.individual.net...
> 
>>Hi,
>>
>>I can't locate MIG in coregen on Solaris 9.2 and ip update 2?
>>
>>Is it only on Linux and Windows?
>>
>>/michael 
> 
> 
> 

Such a pain, I wish Xilinx could port everything to Solaris AMD in the 
next generation tools since simulation and more is already there only 
FPGA stuff left (:


cheers

michael

Article: 127772
Subject: Re: Spartan 3E Sarter Kit Ethernet
From: Siva Velusamy <siva.velusamy@xilinx.com>
Date: Mon, 07 Jan 2008 15:52:34 -0800
Links: << >>  << T >>  << A >>
Pavel.Schukin@gmail.com wrote:
> Hello.
> Would you please to get me some information about how can i realize
> UDP transmition with Spartan 3E Starter Kit? Can i use IP supplied
> with EDK in conjunction with Microblaze. Can I solve the problem
> without using Microblaze? And last questions: what is difference
> between AccelDSP and System Generator and can I convert some dsp
> floating point algorithm available in C in VHDL block?

You can do this a number of ways, but the easiest would be to use a 
processor based subsystem. Build a system using BSB with MicroBlaze + 
ethernet. Add lwIP for a TCP/UDP software stack.

The right solution would depend on your application ofcourse.

Article: 127773
Subject: Re: Ethernet on recent FPGAs
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 07 Jan 2008 17:35:38 -0800
Links: << >>  << T >>  << A >>
MikeShepherd564@btinternet.com wrote:
> 
> The options seem to be:
> 
> 1) Buy a batch of unique addresses (which isn't cheap and involves
> administrative hassle).  If you're designing a LAN for an airliner I'm
> going to fly on, I'd like you to use this method.
> 

Costs $1,650 for 16,777,216 unique addresses.

http://standards.ieee.org/regauth/oui/forms/

	-hpa

Article: 127774
Subject: Re: Ethernet on recent FPGAs
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Mon, 07 Jan 2008 17:39:16 -0800
Links: << >>  << T >>  << A >>
Nico Coesel wrote:
> 
> Yes and no. Like others already pointed out, devices need a serial
> number anyway. Not just for administration but also to keep track of
> devices. So having a fixed number (MAC address) assigned to unit xyz
> generally saves a lot of trouble.
> 
> Besides, if you are going to generate random MAC addresses you may get
> intermittant errors because fixed MAC addresses are expected. Those
> kind of errors are the last you want on a network.
> 

A bigger issue is that randomness is frequently a premium resource in 
real-life systems.

	-hpa



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
2019JanFebMar2019

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