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 154350

Article: 154350
Subject: Re: ise 32b or 64b?
From: Jon <jon@beniston.com>
Date: Fri, 12 Oct 2012 04:35:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
Well, 32-bit pointers are half the size of 64-bit pointers, so you would expect less memory to be used, but you wouldn't expect all data structures to double in size as they seem to here. 

Cache hit rate should be better if half the amount of memory is used, which could explain the improved performance.

Article: 154351
Subject: My First CPU but.. one problem
From: flz47655 <anon@atomwave.com>
Date: Fri, 12 Oct 2012 10:29:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello to all,
I completed my first CPU in VHDL, an incredibly satisfying feeling! : D
I simulated successfully but I did not understand what it means to a signal colored red in ModelSim: http://imageshack.us/photo/my-images/824/modelsimproblem.png

I notice the signal that is in red has a change of more bits at the same time, it is perhaps hazard or something? How can I eliminate the problem in the case?

The register in question is an SRAM synthesized with normal flip-flop, the writing of a data element in memory involves a change of more bits and seems to require two clock pulses to stabilize the signal ..

VHDL code: http://www.atomwave.com/FPGA/LCPU.zip

Article: 154352
Subject: Re: SPDIF receiver
From: ilia_2s@mail.ru
Date: Fri, 12 Oct 2012 12:38:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
0LLRgtC+0YDQvdC40LosIDMxINC+0LrRgtGP0LHRgNGPIDIwMDbCoNCzLiwgMjA6MDQ6NDIgVVRD
KzMg0L/QvtC70YzQt9C+0LLQsNGC0LXQu9GMIGFyYXZpbmQg0L3QsNC/0LjRgdCw0Ls6DQo+IEhp
DQo+ICAgICAgSW0gcGxhbm5pbmcgdG8gZGVzaWduIGFuIFNQRElGIHJlY2VpdmVyIGZvciBpbXBs
ZW1lbnRhdGlvbiBvbg0KPiBTcGFydGFuIDMgRlBHQSAsIEJ1dCBpbSBub3Qgc3VyZSBob3cgdG8g
Z28gYWJvdXQgdGhlIGRlc2lnbixEb2VzIGFueQ0KPiBvbmUgaGF2ZSBpZGVhcyA/DQo+IFRoYW5r
IHUNCg0KSXMgdGhlcmUgYW55IHJlc3VsdHMgb2YgeW91ciBwcm9qZWN0IG5vdz8=

Article: 154353
Subject: Re: ise 32b or 64b?
From: mmihai <iiahim@yahoo.com>
Date: Fri, 12 Oct 2012 15:12:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, October 12, 2012 4:35:44 AM UTC-7, Jon wrote:
> Well, 32-bit pointers are half the size of 64-bit pointers, so you would expect less memory to be used, but you wouldn't expect all data structures to double in size as they seem to here. 
> 
> Cache hit rate should be better if half the amount of memory is used, which could explain the improved performance.

Yes, I know about the pointers ... however I would not expect the data structures to be only pointers :)

It's harder to comment about the cache since the performance is dependent of the access pattern .... Still the 64b code is supposed to be better since it has access to more CPU registers.

Just for fun, running xst with the simple script:
  help -arch virtex6 -command run
(i.e. print help for run, do nothing).

32b: Total memory usage is 83656 kilobytes
64b: Total memory usage is 274236 kilobytes

Interesting ....

--
mmihai

Article: 154354
Subject: Re: modelsim SE 10.0C SystemC bug about initializing sc_signal
From: "homeless" <3749@embeddedrelated>
Date: Fri, 12 Oct 2012 19:20:41 -0500
Links: << >>  << T >>  << A >>
Yes, I am using the same compiler (gcc 4.2.1) for both versions. I don't
have Modelsim SE 10.1c so I cannot try that. As for the other issue, I
believe gcc 4.5.0 is for 64 bit Modelsim SE 10.1c. It says in the
installation manual file that we should use gcc 4.2.1 for 10.1c 32 bit
version.
I guess I will continue with Modelsim SE 6.6 release. 

PS: Modelsim SE 6.6c does not work (initalize the sc_signal vector)
either.

Thank you for your reply, Hans.


>I assume you are using the same compiler version as that sometimes can 
>also cause issues. If you are not using gcc 4.3.3/4.2.1 (recommended 
>versions for Linux/win32) then I would try that first.
>
>If it still fails then try the latest Modelsim SE 10.1c release (gcc 
>4.5.0/4.2.1) and if that also fails then package up a small testcase 
>with your code and raise a Service Request.
>
>You could also try the 2.2 reference simulator just to add some weight 
>to your SR.
>
>Good luck,
>Hans
>www.ht-lab.com	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154355
Subject: Re: My First CPU but.. one problem
From: Jon <jon@beniston.com>
Date: Sat, 13 Oct 2012 09:48:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
A red signal means you have an X - an unknown value. Probably something not being reset, or you have multiple drivers, driving different values to the same signal.

Article: 154356
Subject: Re: My First CPU but.. one problem
From: Frank Buss <fb@frank-buss.de>
Date: Sun, 14 Oct 2012 01:26:28 +0200
Links: << >>  << T >>  << A >>
Jon wrote:
> A red signal means you have an X - an unknown value. Probably
> something not being reset, or you have multiple drivers, driving
> different values to the same signal.

Is it possible to synthesize multiple drivers? When I try this in VHDL,
it is an error and it doesn't synthesize the design. Maybe with some
"inout" or "buffer" ports?

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Article: 154357
Subject: Re: My First CPU but.. one problem
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Sat, 13 Oct 2012 18:21:56 -0700
Links: << >>  << T >>  << A >>
On 10/13/2012 4:26 PM, Frank Buss wrote:
> Jon wrote:
>> A red signal means you have an X - an unknown value. Probably
>> something not being reset, or you have multiple drivers, driving
>> different values to the same signal.
>
> Is it possible to synthesize multiple drivers? When I try this in VHDL,
> it is an error and it doesn't synthesize the design. Maybe with some
> "inout" or "buffer" ports?
>
That has been my experience with Xilinx tools as well. It's possible 
that he is simulating RTL and not the post-synthesis data though.

BobH


Article: 154358
Subject: Re: My First CPU but.. one problem
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 14 Oct 2012 03:09:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
Frank Buss <fb@frank-buss.de> wrote:
> Jon wrote:
>> A red signal means you have an X - an unknown value. Probably
>> something not being reset, or you have multiple drivers, driving
>> different values to the same signal.

> Is it possible to synthesize multiple drivers? When I try this in VHDL,
> it is an error and it doesn't synthesize the design. Maybe with some
> "inout" or "buffer" ports?

Earlier Xilinx FPGAs had internal tristate buffers. As the chips
got bigger, it became necessary to put buffers along the lines,
and so internal tristates were removed. Even so, the tools 
usually will generate equivalent logic.

-- glen

Article: 154359
Subject: Re: My First CPU but.. one problem
From: Gabor <gabor@szakacs.org>
Date: Sun, 14 Oct 2012 14:54:52 -0400
Links: << >>  << T >>  << A >>
On 10/13/2012 11:09 PM, glen herrmannsfeldt wrote:
> Frank Buss <fb@frank-buss.de> wrote:
>> Jon wrote:
>>> A red signal means you have an X - an unknown value. Probably
>>> something not being reset, or you have multiple drivers, driving
>>> different values to the same signal.
>
>> Is it possible to synthesize multiple drivers? When I try this in VHDL,
>> it is an error and it doesn't synthesize the design. Maybe with some
>> "inout" or "buffer" ports?
>
> Earlier Xilinx FPGAs had internal tristate buffers. As the chips
> got bigger, it became necessary to put buffers along the lines,
> and so internal tristates were removed. Even so, the tools
> usually will generate equivalent logic.
>
> -- glen
>
They won't generate any logic if more than one process drives the
same line and it's not an inout port of each driver.  Synthesis
is therefore an easy way to check for multi-source errors.  I almost
never simulate code intended for synthesis unless I have run it through
synthesis first.  You can spend a lot of time debugging stuff and
then realize you need to start over because you used a non-synthesizable
"feature" of the language.

-- Gabor

Article: 154360
Subject: Re: New(?) fast binary counter for FPGAs without carry logic (e.g.
From: Brian Davis <brimdavis@aol.com>
Date: Sun, 14 Oct 2012 17:43:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
Here are some more links regarding counter & accumulator 
carry techniques.

--------------------
Links to early Xilinx counter app notes:

Ultra-Fast Synchronous Counters in XC3000 & XC4000 FPGAs
http://www.cs.york.ac.uk/rts/docs/Xilinx-datasource-2003-q1/appnotes/xapp014.pdf

Loadable Binary Counters in a XC3000 FPGA
http://www.cs.york.ac.uk/rts/docs/Xilinx-datasource-2003-q1/appnotes/xapp004.pdf

pages 15-18 of Xcell Journal #7
http://www.xilinx.com/publications/archives/xcell/Xcell7.pdf

--------------------
Haven't found a pdf for XAPP 001 yet:
"
" High-Speed Synchronous Prescaler Counter
" (XAPP 001)
"
" This simple design provides a very basic non-loadable,
" up counter with a count-enable control. However, this 
" simplicity permits it to be both the densest and the 
" second fastest design.
"
" A prescaler (CEP/CET) technique is used to gain speed,
" permitting the ripple-carry portion of the counter 
" eight clock periods in which to settle. Without special 
" adaptation, however, this technique precludes loading 
" the counter. As a non-loadable counter, three bits can 
" be implemented in three CLBs (1 CLB/bit), with the least 
" significant six bits requiring only four CLBs; this 
" explains the compactness. Only one TILO delay is incurred
" in the ripple-carry path for each three bits. 
"
 
This technique of making the low N bits run fast, with 
the upper bits running slower by 2^N, should map well 
into a compact yet fast implementation of a non-loadable 
binary counter for your Actel part.

 I.e., use something like the pcounter scheme for the low 
few bits, then make the upper bits with a ripple carry,
enabled by the carry out of the low bits.

 You probably will need to add special timing constraints 
to get the tools to understand the multicycle carry, and
that the ripple chain is a false path after FF reset.

 The advantage of this is that you would now only need to
deskew N LSB's of the counter for straight binary output.

--------------------
ORCA-3 FPGAs had an optional register in the dedicated carry chain:

" Fast-carry logic and routing to adjacent PFUs for 
" nibble-wide, byte-wide, or longer arithmetic functions,
" with the option to register the PFU carry-out.

--------------------
More carry-pipelined accumulator references:

( I've mentioned accumulators because they are a more 
general carry design problem than are counters, and 
because I know where to look for literature describing 
high speed pipelined versions.)

"Direct Digital Synthesizers: Theory, Design and Applications", Vankka
lib.tkk.fi/Diss/2000/isbn9512253186/isbn9512253186.pdf
See pages 48-49 for accumulator pipelining techniques.


"Single Chip 500 MHz Function Generator"
P.H. Saul, W. Barber, D.G. Taylor, T. Ward
IEE Proceedings, Vol. 138, No. 2, pp 239-243, April 1991

Reprinted in "Direct Digital Frequency Synthesizers", Kroupa (ed), IEEE Press, 1999

Fig. 2 shows the one-bit-per-carry accumulator structure
Fig. 5 shows the accumulator output deskew tree

-Brian

Article: 154361
Subject: Re: FPGA-Board for Ethernet
From: Joel Williams <nospamwhydontyoublogaboutit@nospamgmail.com>
Date: Mon, 15 Oct 2012 23:38:57 +1030
Links: << >>  << T >>  << A >>
On 10/10/12 1:10 AM, bln5320@googlemail.com wrote:
> Sorry I was not at work the last days. Thank you very much for the answers and your care.
> I will do as you say and look for a board with Xilinx ISE.
> The Diligent Boards are looking good.
> I think it will be the Spartan 3E Starter Board:
> http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,792&Prod=S3EBOARD
> Or the Atlys™ Spartan-6 FPGA Development Board
> http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS
>
> Do I need an Gigabit-Ethernet PHY?

If you're doing gigabit Ethernet, then yes. Note that most gigabit PHYs 
also work at 10 and 100 Mbps.

> Do I need 2 RJ-45 Interfaces?

Depends on what you want to do with it.

> Or can I connect the UTP Cable directly the the FPGA pins.

You can certainly connect a UTP cable directly to an FPGA (like you 
could with any piece of wire), but it might not do what you want. High 
speed Ethernet usually uses a parallel interface (GMII/MII, etc.) that 
the PHY converts to one of the physical layer Ethernet standards. Most 
FPGAs aren't capable of generating the correct logic levels necessary 
for Ethernet directly, which is why you need a PHY.

> Or something like UTP to RJ-45 and the PC with usb?

Not sure what you mean by that!

> For further Information about the used ethernet  you can look at the Figure 5 its the Broadcom Ethernet
> http://itersnews.com/?p=10541

If you want to use Automotive Ethernet, I would recommend that you use 
an Automotive Ethernet PHY. They're not very common on FPGA development 
boards, so you might need to do some PCB design for this.

Joel



Article: 154362
Subject: Re: My First CPU but.. one problem
From: jonesandy@comcast.net
Date: Mon, 15 Oct 2012 07:12:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, October 14, 2012 1:55:03 PM UTC-5, Gabor wrote:
 They won't generate any logic if more than one process drives the same line and it's not an inout port of each driver. 

That's not correct. All you need is an OUT port, a resolved type, and conditionally drive 'Z' on that port. INOUT has nothing to do with it, unless you want to read the result of the (resolved) bus inside one of the modules that drives it.

Andy

Article: 154363
Subject: Re: My First CPU but.. one problem
From: flz47655 <anon@atomwave.com>
Date: Mon, 15 Oct 2012 07:42:17 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thank you to all,
Thank you very much for your valuable informations.

I've adjusted code and removed red warning in Modelsim with: 

case state is
	-- ...
	when sexec =>				
		-- Read data
		case data(7 downto 6) is
			-- ...
			-- Store
			when "01" => 
				we 	<= '1';					
				addr 	<= data(5 downto 0);							
				state <= sstore;
			-- ...
		end case;						
	when sstore =>
		-- write to memory, data is ready next clock								
		data 	<= reg;
		state <= sfetch;
	when others => null;
end case;

I just moved:

data <= reg;

In the state sstore.

So using high impedance Z signals in design is a worst practice?

Thank you

Article: 154364
Subject: Re: My First CPU but.. one problem
From: jonesandy@comcast.net
Date: Mon, 15 Oct 2012 08:34:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, October 15, 2012 9:42:17 AM UTC-5, flz47655 wrote:
> So using high impedance Z signals in design is a worst practice?=20

Not necessarily. Some work groups or organizations discourage it. If I use =
it (inside an FPGA, instead of on IO), I heavily comment what is supposed t=
o happen, and perhaps why a more explicit approach is not preferable.=20

A fuzzy area is called "pushing tri-states" (through registers). We often n=
eed registered, tri-stated IO, and an easy (to read and write) way to do it=
 is to assign 'Z's to the output register. Of course registers cannot reall=
y hold a 'Z', but the synthesis tool recognizes this, inserts a tri-state b=
uf after the register AND inserts a register for the (implied) tri-state bu=
f enable signal. Note that if you reset a register to 'Z', then the real re=
set on the real data register is not truly defined. The RTL code still dete=
rmines what the first (non-Z) assignment after reset will be, so it really =
does not matter. I don't recall whether the synthesis tool left the data re=
gister reset off, or defaulted the reset value to '0'. I would imagine that=
 if it affects pushing the registers et al into the IO block (e.g. if all r=
egisters in the IOB must have a common reset), the synthesis tool will "do =
the right thing".

Inside an FPGA, an interesting side-effect of tri-state to mux synthesis is=
 that the tri-state enable signals are assumed to be mutually exclusive (ot=
herwise it would not have worked for a real tri-state bus), which reduces t=
he complexity of the mux. This may be an easier way to get the simpler mux =
than to explictly code the AND-OR tree. It also allows the mux control/code=
 to be distributed amongst multiple modules. The same can be done with at l=
east the AND gating of an explicilty coded AND-OR tree.

Also, an INOUT tristate port on an internalal bus/module is automatically i=
mplemented as three signals (an output & enable to the mux, and an input fr=
om the mux). Whether that is more readable/writeable/maintainable than a mo=
re explicit description with two ports and an external mux is dependent upo=
n the application and the design team/customer. (YMMV) If the application a=
llows, I tend to favor higher levels of abstraction over more explicit desc=
riptions of hardware.

Andy

Article: 154365
Subject: Re: My First CPU but.. one problem
From: Frank Buss <fb@frank-buss.de>
Date: Mon, 15 Oct 2012 21:02:50 +0200
Links: << >>  << T >>  << A >>
flz47655 wrote:

> So using high impedance Z signals in design is a worst practice?

You need it, if you want to implement an open collector output, e.g. for
implementing I2C. I've never needed it inside a FPGA.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Article: 154366
Subject: Re: My First CPU but.. one problem
From: rickman <gnuarm@gmail.com>
Date: Mon, 15 Oct 2012 18:17:19 -0400
Links: << >>  << T >>  << A >>
On 10/15/2012 10:12 AM, jonesandy@comcast.net wrote:
> On Sunday, October 14, 2012 1:55:03 PM UTC-5, Gabor wrote:
>   They won't generate any logic if more than one process drives the same line and it's not an inout port of each driver.
>
> That's not correct. All you need is an OUT port, a resolved type, and conditionally drive 'Z' on that port. INOUT has nothing to do with it, unless you want to read the result of the (resolved) bus inside one of the modules that drives it.
>
> Andy

Like someone said earlier, FPGAs no longer have tristate buffers in 
them.  If this is an external pin, then a 'Z' can be driven, but I'm 
still not sure it will synthesize with multiple drivers.

Rick

Article: 154367
Subject: Re: My First CPU but.. one problem
From: Gabor <gabor@szakacs.org>
Date: Mon, 15 Oct 2012 20:46:06 -0400
Links: << >>  << T >>  << A >>
On 10/15/2012 10:12 AM, jonesandy@comcast.net wrote:
> On Sunday, October 14, 2012 1:55:03 PM UTC-5, Gabor wrote:
>   They won't generate any logic if more than one process drives the same line and it's not an inout port of each driver.
>
> That's not correct. All you need is an OUT port, a resolved type, and conditionally drive 'Z' on that port. INOUT has nothing to do with it, unless you want to read the result of the (resolved) bus inside one of the modules that drives it.
>
> Andy
>
On the other hand if one process is assigning 'Z', then he shouldn't
get 'X' on the simulation.  My point was that a normal signal can't
generally be driven by more than one process for synthesis within the
same entity or architecture.  In Verilog this is certainly enforced
for "reg" types, whether they are assigned 'Z' or not.  None of
this is an error for simulation, and unless you happen to notice the
'X' for the multiple-driven case, you could do a lot of design debug
and then realize you need to do a lot of re-coding to get it to
synthesize.

-- Gabor

Article: 154368
Subject: DIGILENT DESIGN CONTEST 2013
From: Digilent RO <cristina.dabacan@gmail.com>
Date: Tue, 16 Oct 2012 01:23:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
We proudly announce the 9th annual Digilent Design Contest Europe, organize=
d within the Technical University of Cluj-Napoca, Rom=E2nia and sponsored b=
y Digilent!
The goal of this international student contest is to encourage students to =
develop their engineering hardware and software skills. We invite teams of =
students (one or two members) from all over Europe, to put in practice thei=
r ideas. Teams will have approximately 6 months to design and implement a p=
roject (FPGA or microcontroller) of their choice and present the final vers=
ion in May 2013 in Cluj-Napoca, Rom=E2nia.=20
Students will be provided state-of-the-art Digilent FPGA or microcontroller=
 boards as well as peripheral modules to develop their projects. Please vis=
it our website: http://www.digilent.ro  to see all our products, especially=
 the ones recommended for this year competition.
Visit us on the web for more information about the European Contest or writ=
e to: contestEU@digilentinc.com=20
The most creative and complex solutions are rewarded with generous prizes!=
=20
Please forward this information to university students, especially from com=
puter science or electrical engineering majors. We would appreciate receivi=
ng a feedback about whether this information presents any interest for you =
or not.
Apart from the Digilent Contest Europe, there will be regional editions of =
the contest, to which you can apply. We encourage students to enroll in the=
 regional contest that is convenient for them. More information about the e=
vent can be found at http://www.digilentinc.com/events/ddc2013/. Also see o=
ur previous events and the successful Munich Worldwide Finals.
Sincerely,
The Digilent Team

Article: 154369
Subject: Re: FPGA-Board for Ethernet
From: bln5320@googlemail.com
Date: Tue, 16 Oct 2012 06:32:52 -0700 (PDT)
Links: << >>  << T >>  << A >>

>=20
> > Sorry I was not at work the last days. Thank you very much for the answ=
ers and your care.
>=20
> > I will do as you say and look for a board with Xilinx ISE.
>=20
> > The Diligent Boards are looking good.
>=20
> > I think it will be the Spartan 3E Starter Board:
>=20
> > http://www.digilentinc.com/Products/Detail.cfm?NavPath=3D2,400,792&Prod=
=3DS3EBOARD
>=20
> > Or the Atlys=EF=BF=BD Spartan-6 FPGA Development Board
>=20
> > http://www.digilentinc.com/Products/Detail.cfm?NavPath=3D2,400,836&Prod=
=3DATLYS
>=20
> >
>=20
> > Do I need an Gigabit-Ethernet PHY?
>=20
>=20
>=20
> If you're doing gigabit Ethernet, then yes. Note that most gigabit PHYs=
=20
>=20
> also work at 10 and 100 Mbps.
>=20
>=20
>=20
> > Do I need 2 RJ-45 Interfaces?
>=20
>=20
>=20
> Depends on what you want to do with it.
>=20
>=20
>=20
> > Or can I connect the UTP Cable directly the the FPGA pins.
>=20
>=20
>=20
> You can certainly connect a UTP cable directly to an FPGA (like you=20
>=20
> could with any piece of wire), but it might not do what you want. High=20
>=20
> speed Ethernet usually uses a parallel interface (GMII/MII, etc.) that=20
>=20
> the PHY converts to one of the physical layer Ethernet standards. Most=20
>=20
> FPGAs aren't capable of generating the correct logic levels necessary=20
>=20
> for Ethernet directly, which is why you need a PHY.
>=20
>=20
>=20
> > Or something like UTP to RJ-45 and the PC with usb?
>=20
>=20
>=20
> Not sure what you mean by that!
>=20
>=20
>=20
> > For further Information about the used ethernet  you can look at the Fi=
gure 5 its the Broadcom Ethernet
>=20
> > http://itersnews.com/?p=3D10541
>=20
>=20
>=20
> If you want to use Automotive Ethernet, I would recommend that you use=20
>=20
> an Automotive Ethernet PHY. They're not very common on FPGA development=
=20
>=20
> boards, so you might need to do some PCB design for this.
>=20
>=20
>=20
> Joel

Thank you.=20
I've got an automtive phy now, so i have to implement the MAC Layer on the =
FPGA and thats it. I've found the opencores at opencores.org

So Thank you very much :)

Article: 154370
Subject: Re: My First CPU but.. one problem
From: jonesandy@comcast.net
Date: Tue, 16 Oct 2012 10:34:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
In vhdl, you can use unresolved data types to disallow multiple drivers. You can still drive 'Z' with std_ulogic or std_ulogic_vector, but you can only have one driver.

I seem to remember Modlesim showing waves in red if the trace included meta-values (W, Z, X, -, U), maybe if you had the radix set to something besides binary? If that is the case, it would not necessarily indicate contention between drivers.

Andy

Article: 154371
Subject: .do files... why?
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Tue, 16 Oct 2012 10:39:51 -0700
Links: << >>  << T >>  << A >>
Alright, I've got to fess up.  I'm lost as to the point of .do files.
They seem to suffer through all of Tcl's wacky syntax, but with the
added benefit of not giving you access to the standard Tcl commands.

Am I missing something here?  Or is the entire point of the exercise
that Tcl is considered to be intimidating, whereas a proprietary macro
language is not?

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 154372
Subject: Re: My First CPU but.. one problem
From: Gabor <gabor@szakacs.invalid>
Date: Tue, 16 Oct 2012 14:45:19 -0400
Links: << >>  << T >>  << A >>
jonesandy@comcast.net wrote:
> In vhdl, you can use unresolved data types to disallow multiple drivers. You can still drive 'Z' with std_ulogic or std_ulogic_vector, but you can only have one driver.
> 
> I seem to remember Modlesim showing waves in red if the trace included meta-values (W, Z, X, -, U), maybe if you had the radix set to something besides binary? If that is the case, it would not necessarily indicate contention between drivers.
> 
> Andy

Modelsim (in the default color scheme) shows Z in blue and most other
meta-values in red.  If any bits of a vector are not 0, 1 or Z, then the
whole vector gets colored red unless you expand it to show individual
bits.  This has nothing to do with the display radix.  You can see
binary values like "01XX0XX0" in the waveform originally posted.  Just
under it you can see the individual bits as waves, and only those with
"X" values show up in red.  If you have a sufficient license (I don't
think the vendor-bundled editions did this) you can double-click on
the red lines to trace back to the driver(s).

And the multi-driver issue was a "side-thread" to this topic.  There
are many ways to end up with X or U in simulation.

-- Gabor

Article: 154373
Subject: Phase 15.18 placement optimization
From: "Andrew Holme" <ah@nospam.com>
Date: Tue, 16 Oct 2012 20:24:14 +0100
Links: << >>  << T >>  << A >>
I'm working on a Virtex 5 project containing a 13-stage pipeline clocked at 
200 MHz.  The data path gets quite wide in the latter stages; but only 11% 
of available slices are used; so the FPGA is relatively empty.  Every other 
step in the build process rips through quickly, except the above named MAP 
stage, which accounts for 98% of total build time.  Routing is over in a 
flash, and the result meets timing.  I would like to reduce the build time 
and I was wondering how to go about it.  One idea was to create LOC 
constraints on logic, perhaps based on where the tools themselves placed it 
after a previous optimization run.  Any other suggestions?

TIA


Article: 154374
Subject: Re: .do files... why?
From: gtwrek@sonic.net (Mark Curry)
Date: Wed, 17 Oct 2012 02:00:25 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <20121016103951.01e68467@rg.highlandtechnology.com>,
Rob Gaddi  <rgaddi@technologyhighland.invalid> wrote:
>Alright, I've got to fess up.  I'm lost as to the point of .do files.
>They seem to suffer through all of Tcl's wacky syntax, but with the
>added benefit of not giving you access to the standard Tcl commands.
>
>Am I missing something here?  Or is the entire point of the exercise
>that Tcl is considered to be intimidating, whereas a proprietary macro
>language is not?

If you're talking about Modelsim - I was under the impression that they 
were one in the same.  We seem to name our modelsim scripts haphazardly -
some .tcl, some .do

Perhaps .tcl is intended for pure tcl, and .do is intended for "tcl" plus
modelsim builtins?  I dunno.  Never given it too much thought...

--Mark





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