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 154700

Article: 154700
Subject: USB power and debug signals on micro USB connector
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Thu, 20 Dec 2012 11:36:26 +0100
Links: << >>  << T >>  << A >>
For a handheld device, powered by a Li-ion cell, I need a charge power
input. Most standard chips for charging and powering the device are
meant for USB power or simular. Since the current standard charging
connector for mobile phones is a micro USB connector, it seems best to
use that. It means you can use a lot of standard chargers. Agreed?

For the device, I also need a serial debug connection. It is OK to have
the 3V3 UART connection on an internal header. This means the device
must be opened for debugging and maybe a slot must be made in the
enclosure for longer test sessions with enclosure.

But is it possible and/or advisable to use the spare pins on the micro
USB connector to bring out the 3V3 UART signals? It would save a header
and make debugging in the enclosure a lot simpler. But it must not
lead to damage to the device and or (windows/linux/mac) PC when the
device is plugged in to a PC. There must not be any strange behaviour on
the PC and preferably there must not be any detection by the OS of USB
activity.

You could ofcourse use a real USB/serial connection, but that would
mean adding an FTDI chip or a big software effort on the DSP (which has
USB hardware). It would also mean every PC user has acces to the debug
channel, I'm not sure we want that.

So putting the 3V3 UART signals (TX/RX only) on the micro USB and use
a special breakout box (possibly with FTDI chip) for debugging seems the
most practical solution for now. Any arguments against it? Any
experiences with such a setup? And which signal on which pin for least
chance on damage and strange behaviour? I know some USB chargers have
shorts or resistors on the datalines, so at least a few protection
resistors on the device side are required.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

To the systems programmer, users and applications serve only to provide a
test load.

Article: 154701
Subject: Re: USB power and debug signals on micro USB connector
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 20 Dec 2012 12:59:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote:

> For a handheld device, powered by a Li-ion cell, I need a charge power
> input. Most standard chips for charging and powering the device are
> meant for USB power or simular. Since the current standard charging
> connector for mobile phones is a micro USB connector, it seems best to
> use that. It means you can use a lot of standard chargers. Agreed?
 
> For the device, I also need a serial debug connection. It is OK to have
> the 3V3 UART connection on an internal header. This means the device
> must be opened for debugging and maybe a slot must be made in the
> enclosure for longer test sessions with enclosure.

You mean USB and serial at the same time?

It seems usual for USB mouse to also work as a PS/2 mouse with
the same lines and a connector/adaptor. But it is one or the other.
 
> But is it possible and/or advisable to use the spare pins on the micro
> USB connector to bring out the 3V3 UART signals? It would save a header
> and make debugging in the enclosure a lot simpler. But it must not
> lead to damage to the device and or (windows/linux/mac) PC when the
> device is plugged in to a PC. There must not be any strange behaviour on
> the PC and preferably there must not be any detection by the OS of USB
> activity.

I think you should be at least 5V safe. The way to do that with 3V3
lines is well known, especially for slow signals. (I think you only
need resistors.) 
 
> You could ofcourse use a real USB/serial connection, but that would
> mean adding an FTDI chip or a big software effort on the DSP (which has
> USB hardware). It would also mean every PC user has acces to the debug
> channel, I'm not sure we want that.
 
> So putting the 3V3 UART signals (TX/RX only) on the micro USB and use
> a special breakout box (possibly with FTDI chip) for debugging seems the
> most practical solution for now. Any arguments against it? 
> Any experiences with such a setup? And which signal on which pin 
> for least chance on damage and strange behaviour? 

I believe it is current limiting resistors, as long as the
signals aren't too fast.

> I know some USB chargers have shorts or resistors on the 
> datalines, so at least a few protection
> resistors on the device side are required.
 
As I understand it, USB devices requiring more than the default
Icc are supposed to negotiate with the host. That is hard to
do when the host is just a power adaptor, so there seem to be
conventions for the voltages on the data lines that allow devices
to pull more current. That is, for example, how iPod chargers work.

You might also want to do that.

-- glen

Article: 154702
Subject: Re: FPGA DSP basics: clock enable / new clock
From: Dave <doomeddave@yahoo.co.uk>
Date: Thu, 20 Dec 2012 05:22:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, December 20, 2012 9:58:23 AM UTC, o pere o wrote:
> On 12/19/2012 11:55 PM,  wrote:
> 
> > On Dec 19, 9:32 am, o pere o <m...@somewhere.net> wrote:
> 
> >> My current goal is to implement some digital signal processing (filters)
> 
> >> on a FPGA. I am currently using Terasics DE0 nano board. This board has
> 
> >> an ADC128S022 ADC. I have started as follows:
> 
> >>
> 
> >>   From the 50 MHz board reference I derive a 25.6 MHz signal with a PLL.
> 
> >>   From this clock I generate the signals required to drive the ADC,
> 
> >> essentially a clock at 3.2 MHz. Every 16 clock cycles, the ADC gives a
> 
> >> 12 bit sample. This translates into 200 ksps. I generate a signal
> 
> >> "smpl_rdy" at the appropriate position which allows me to latch the 8
> 
> >> most significant bits.
> 
> >>
> 
> >> The main question is how should I do the signal processing:
> 
> >>
> 
> >> a) Using the 25.6 MHz clock and using smpl_rdy as a clock enable
> 
> >> b) Deriving a new 200 kHz clock from the PLL
> 
> >>
> 
> >> I have done some projects on FPGAs but they were quite simple, so I
> 
> >> consider myself only a little more than a beginner. I can think of some
> 
> >> problems with both approaches, but I may have overlooked may others:
> 
> >>
> 
> >> For instance, if I followed a), I guess that Quartus II would think that
> 
> >> the processing happens at 25.6 MHz: if there is a long combinational
> 
> >> path between registers, the timing analyzer will not be able to figure
> 
> >> out that the data and the enable signal are stable during 16 clock
> 
> >> cycles. Is there a way to provide this info to Quartus II? OTOH, using
> 
> >> the same signal as an enable for everything further down does not seem
> 
> >> sound enough, thinking of fanouts. So what?
> 
> >>
> 
> >> If I tried to follow b), how would I ensure that there is the proper
> 
> >> phase relationship between both clocks? Is there a way to achieve this?
> 
> >>
> 
> >> Thanks for any advice.
> 
> >>
> 
> >> Pere
> 
> >
> 
> > Do you need the 25.6MHz or could you do everything synchronous on a
> 
> > 3.2MHz ?
> 
> > Then, even without telling it that you have multi cycles paths, timing
> 
> > should
> 
> > be easy
> 
> 
> 
> In this case, I could do everything at a much lower frequency. As I have
> 
> to generate the signals to control the ADC, my approach has been to 
> 
> start with a system frequency at least 2x the ADC clock frequency that I 
> 
> have to generate. So, I could work with 6.4MHz and timing would be much 
> 
> easier. However, the main point of my question was to learn the proper 
> 
> way to do this.
> 
> 
> 
> > But also consider that for a lower clock rate you might need more
> 
> > resources
> 
> >
> 
> > i.e. filter running at 25.6MHz might only need one mul-acc, where a
> 
> > filter
> 
> > running at 3.2MHz needs 8
> 
> 
> 
> That's certainly true!
> 
> 
> 
> BTW, any inputs on whether using my smpl_rdy as an enable for each 
> 
> register is a good/bad idea?

That is how I would do it for sure in this case.


> 
> 
> 
> > -Lasse
> 
> >
> 
> Thanks for your inputs!
> 
> 
> 
> Pere


Article: 154703
Subject: Re: USB power and debug signals on micro USB connector
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Thu, 20 Dec 2012 14:34:15 +0100
Links: << >>  << T >>  << A >>
In comp.arch.fpga,
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>
>
Sorry , wrong group!

I'll re-post in comp.arch.embedded


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

For most men life is a search for the proper manila envelope in which to
get themselves filed.
		-- Clifton Fadiman

Article: 154704
Subject: Re: USB power and debug signals on micro USB connector
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Thu, 20 Dec 2012 14:58:00 +0100
Links: << >>  << T >>  << A >>
In comp.arch.fpga,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Stef <stef33d@yahooi-n-v-a-l-i-d.com.invalid> wrote:
>

Sorry, I meant to post this to comp.arch.embedded.
Re-posted it there, I'll try to cancel it here.
If you can, put any replies over there. But I'll keep reading here
for any replies.

>> For a handheld device, powered by a Li-ion cell, I need a charge power
>> input. Most standard chips for charging and powering the device are
>> meant for USB power or simular. Since the current standard charging
>> connector for mobile phones is a micro USB connector, it seems best to
>> use that. It means you can use a lot of standard chargers. Agreed?
>  
>> For the device, I also need a serial debug connection. It is OK to have
>> the 3V3 UART connection on an internal header. This means the device
>> must be opened for debugging and maybe a slot must be made in the
>> enclosure for longer test sessions with enclosure.
>
> You mean USB and serial at the same time?

No, I just need the USB for power. I want to use the 'spare' lines
for serial. 

> It seems usual for USB mouse to also work as a PS/2 mouse with
> the same lines and a connector/adaptor. But it is one or the other.
>  
>> But is it possible and/or advisable to use the spare pins on the micro
>> USB connector to bring out the 3V3 UART signals? It would save a header
>> and make debugging in the enclosure a lot simpler. But it must not
>> lead to damage to the device and or (windows/linux/mac) PC when the
>> device is plugged in to a PC. There must not be any strange behaviour on
>> the PC and preferably there must not be any detection by the OS of USB
>> activity.
>
> I think you should be at least 5V safe. The way to do that with 3V3
> lines is well known, especially for slow signals. (I think you only
> need resistors.) 

Protecting my device is probably the the easiest problem. But how to keep
the PC from sensing there is anything on the USB and emiting a 'connect
sound' for instance?

>> You could ofcourse use a real USB/serial connection, but that would
>> mean adding an FTDI chip or a big software effort on the DSP (which has
>> USB hardware). It would also mean every PC user has acces to the debug
>> channel, I'm not sure we want that.
>  
>> So putting the 3V3 UART signals (TX/RX only) on the micro USB and use
>> a special breakout box (possibly with FTDI chip) for debugging seems the
>> most practical solution for now. Any arguments against it? 
>> Any experiences with such a setup? And which signal on which pin 
>> for least chance on damage and strange behaviour? 
>
> I believe it is current limiting resistors, as long as the
> signals aren't too fast.
>
Guess that will work.


>> I know some USB chargers have shorts or resistors on the 
>> datalines, so at least a few protection
>> resistors on the device side are required.
>  
> As I understand it, USB devices requiring more than the default
> Icc are supposed to negotiate with the host. That is hard to
> do when the host is just a power adaptor, so there seem to be
> conventions for the voltages on the data lines that allow devices
> to pull more current. That is, for example, how iPod chargers work.
>
> You might also want to do that.

There is an 'apple convention' for signalling power need. The only
other 'standard' I know is for USB chargers. They should have D+ and
D- shorted to signal the device it can draw 1A?

My worry is not about the power. It is OK if my device does not charge
(properly) when connected to a PC. The user should use the specified
charger. It may be 'nice to have' to allow for charging from a PC. So
it is worth to look in to this a little. But I will not implement the
proper USB negotiation, as I do not have USB device software running.
But maybe with some sensing it is possible to limit the power draw to
only 100mA when connected to a PC.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

This night methinks is but the daylight sick.
		-- William Shakespeare, "The Merchant of Venice"

Article: 154705
Subject: Xilinx FIFO usage
From: "Valdez" <3995@embeddedrelated>
Date: Thu, 20 Dec 2012 18:49:56 -0600
Links: << >>  << T >>  << A >>
It is my first time here, so hello everybody! :)

I have problems with Xilinx FIFO on Spartan 3. As far as I understand it,
standard FIFO sends data out in the next clock cycle after I set 'rd_en'
signal to '1'. In my case I get output not in the next, but in the second
clock cycle. Do you know what may cause that problem? 

Here is what I do (first I put in FIFO two byte words):
STATE1 => if FIFO is not empty then 'rd_en' to '1', go to STATE2,
STATE2 => I keep 'rd_en' equal '1', and go to STATE3, (the output here is
zero),
STATE3 => I know there were two byte words so  'rd_en' to '0', here I can
get first byte, and I go to STATE4,
STATE4 => 'rd_en' still '0', I can get second byte, then I go and stay into
IDLE state.

Every state last one clock cycle, instead of STATE1 where I wait for not
empty FIFO and IDLE obviously after all.

Regards,
Valdez

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154706
Subject: Re: Xilinx FIFO usage
From: Sean Durkin <news_dec12@tuxroot.de>
Date: Fri, 21 Dec 2012 08:02:24 +0100
Links: << >>  << T >>  << A >>
Valdez wrote:
> It is my first time here, so hello everybody! :)
>
> I have problems with Xilinx FIFO on Spartan 3. As far as I understand it,
> standard FIFO sends data out in the next clock cycle after I set 'rd_en'
> signal to '1'. In my case I get output not in the next, but in the second
> clock cycle. Do you know what may cause that problem?

I suppose you are using a FIFO generated with Core Generator? There is 
an option there to "use embedded registers". If you enable that, a 
register stage will be added at the FIFO output, adding one clock cycle 
of delay. But I believe that is not your problem, see below.

> Here is what I do (first I put in FIFO two byte words):
> STATE1 => if FIFO is not empty then 'rd_en' to '1', go to STATE2,
> STATE2 => I keep 'rd_en' equal '1', and go to STATE3, (the output here is
> zero),
> STATE3 => I know there were two byte words so  'rd_en' to '0', here I can
> get first byte, and I go to STATE4,
> STATE4 => 'rd_en' still '0', I can get second byte, then I go and stay into
> IDLE state.

So you expect to get the first data word in STATE2? I suppose you have 
your state machine in a clocked process. If you look at the simulation, 
you should be able to see that the rd_en-signal you set to '1' in STATE1 
doesn't go high until you reach STATE2. That's because rd_en is the 
output of a flip flop and will not be updated until the next rising edge 
of the clock (or falling edge, if that's how you wrote it).

One clock cycle later (by then you've reached STATE3) the first data 
word appears at the FIFO output, so everything's "logical" and behaves 
the way that it should (data is available one clock cycle after rd_en is 
set to '1').

Hope that helps,
Sean

Article: 154707
Subject: Re: Xilinx FIFO usage
From: "Valdez" <3995@embeddedrelated>
Date: Fri, 21 Dec 2012 02:57:47 -0600
Links: << >>  << T >>  << A >>
>Valdez wrote:
>> It is my first time here, so hello everybody! :)
>>
>> I have problems with Xilinx FIFO on Spartan 3. As far as I understand
it,
>> standard FIFO sends data out in the next clock cycle after I set
'rd_en'
>> signal to '1'. In my case I get output not in the next, but in the
second
>> clock cycle. Do you know what may cause that problem?
>
>I suppose you are using a FIFO generated with Core Generator? There is 
>an option there to "use embedded registers". If you enable that, a 
>register stage will be added at the FIFO output, adding one clock cycle 
>of delay. But I believe that is not your problem, see below.
>
>> Here is what I do (first I put in FIFO two byte words):
>> STATE1 => if FIFO is not empty then 'rd_en' to '1', go to STATE2,
>> STATE2 => I keep 'rd_en' equal '1', and go to STATE3, (the output here
is
>> zero),
>> STATE3 => I know there were two byte words so  'rd_en' to '0', here I
can
>> get first byte, and I go to STATE4,
>> STATE4 => 'rd_en' still '0', I can get second byte, then I go and stay
into
>> IDLE state.
>
>So you expect to get the first data word in STATE2? I suppose you have 
>your state machine in a clocked process. If you look at the simulation, 
>you should be able to see that the rd_en-signal you set to '1' in STATE1 
>doesn't go high until you reach STATE2. That's because rd_en is the 
>output of a flip flop and will not be updated until the next rising edge 
>of the clock (or falling edge, if that's how you wrote it).
>
>One clock cycle later (by then you've reached STATE3) the first data 
>word appears at the FIFO output, so everything's "logical" and behaves 
>the way that it should (data is available one clock cycle after rd_en is 
>set to '1').
>
>Hope that helps,
>Sean
>

Sure that helps :)
I am new at this and always forgot that signals value is changed after
clock cycle. Thanks for reminder.
I will have to check this in ISim on Windows, because I can't run it on
Ubuntu.

But I don't see now how to get data in situation, when I switch between two
states in a clocked process. In first state I'd like to get data byte, in
the second I don't want next byte. Then I go back to the first... it will
be repeated 512 times. Could you please give me idea for such an
algorithm?

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154708
Subject: Re: FPGA DSP basics: clock enable / new clock
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Fri, 21 Dec 2012 02:29:20 -0800 (PST)
Links: << >>  << T >>  << A >>
On 19 Dez., 11:17, o pere o <m...@somewhere.net> wrote:
> On 12/19/2012 10:19 AM, Thomas Stanka wrote:
>
>
>
> > On 19 Dez., 09:32, o pere o <m...@somewhere.net> wrote:
> >> My current goal is to implement some digital signal processing (filter=
s)
> >> on a FPGA. I am currently using Terasics DE0 nano board. This board ha=
s
> >> an ADC128S022 ADC. I have started as follows:
>
> >> =A0 From the 50 MHz board reference I derive a 25.6 MHz signal with a =
PLL.
> >> =A0 From this clock I generate the signals required to drive the ADC,
> >> essentially a clock at 3.2 MHz. Every 16 clock cycles, the ADC gives a
> >> 12 bit sample. This translates into 200 ksps. I generate a signal
> >> "smpl_rdy" at the appropriate position which allows me to latch the 8
> >> most significant bits.
>
> >> The main question is how should I do the signal processing:
>
> >> a) Using the 25.6 MHz clock and using smpl_rdy as a clock enable
> >> b) Deriving a new 200 kHz clock from the PLL
>
> > If you have not that much experience try to use only _one_ clock for
> > everything in the FPGA, this gives a synchronous design. As this clock
> > is higher than the ADC clock you can easily treat the signals from ADC
> > as asynchronous, and get them still proper (oversampling of ready,
> > allows you to determine, when the data is stable).
> > The easiest design is complete synchronous with only one clock and
> > considering all inputs as asynchronous. The frequencies you mention
> > indicate no reason, why that should not be possible in your case.
>
> Well, this is just to get started. Once I'm running I will try to speed
> everything up as much as possible, just to learn something from it :)
> So, I'd also like to know "the" way to do it right.
>
> BTW, I don't understand what you mean saying that I can treat the
> signals as asynchronous: At a given time point in the ADC serial stream,
> I generate a 1-clock-wide signal that indicates that the data is ready.
> In the approach a) I plan to use this signal as an enable for all the
> registers in the processing path.
>
> main clock TTTTTTTTTTTTTTTTTTTTTT....TTTTTTTTTTTTTTT
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _____ =A0 =A0 _____ =A0 =A0 =A0 =A0 =A0 =
=A0_____
> ADC =A0clock ____ =A0 =A0 _____ =A0 =A0 ___...._____ =A0 =A0 ___...
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0_
> smpl_rdy =A0 _________________________________ _____...
>
> =A0From all this, I would say that I am doing a fully synchronous design.

As Rickman already stated there are ways to do this right and more
ways to do it wrong.
Synchronous design means same frequency with _known_ phase relation
(within a reasonable window) of clock at all nodes at which you use
the clock.
Same frequency but unknown phase relation should be considered
asynchronous if you could not guarantee, that the phase will not drift
over a certain edge that leads to undesired behavior.

bye Thomas









Article: 154709
Subject: Re: Xilinx FIFO usage
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri, 21 Dec 2012 11:48:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Fri, 21 Dec 2012 02:57:47 -0600, Valdez wrote:

>>Valdez wrote:

> I will have to check this in ISim on Windows, because I can't run it on
> Ubuntu.

Why not? I've been running ISim on both OpenSuse 11.x and Debian, so it 
ought to run on Ubuntu. 

(There may be some dependency you have to install, or some path to fix, 
but that's about it...)

- Brian

Article: 154710
Subject: Re: Xilinx FIFO usage
From: "Valdez" <3995@embeddedrelated>
Date: Fri, 21 Dec 2012 07:02:17 -0600
Links: << >>  << T >>  << A >>
>On Fri, 21 Dec 2012 02:57:47 -0600, Valdez wrote:
>
>>>Valdez wrote:
>
>> I will have to check this in ISim on Windows, because I can't run it on
>> Ubuntu.
>
>Why not? I've been running ISim on both OpenSuse 11.x and Debian, so it 
>ought to run on Ubuntu. 
>
>(There may be some dependency you have to install, or some path to fix, 
>but that's about it...)
>
>- Brian
>
Yes, missing libraries. I tried to follow some instructions, but I can't
run ISim when the project includes Core Generator modules. I will try
during Xmas, when will be more time and no access to hardware :)	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154711
Subject: pBlazSIM
From: trayres@gmail.com
Date: Mon, 24 Dec 2012 06:19:18 -0800 (PST)
Links: << >>  << T >>  << A >>
I'm having a hell of a time getting started with the pBlazSIM and pBlazASM toolchain. Does anyone have a good resource?

Article: 154712
Subject: Re: Which to learn: Verilog vs. VHDL?
From: joey899244@yahoo.cn
Date: Fri, 28 Dec 2012 00:28:19 -0800 (PST)
Links: << >>  << T >>  << A >>
it is all very fuzzy now. http://www.hqew.net/product-data/LM317T

Article: 154713
Subject: Re: Looking for evaluators for NEW Vector Processor for FPGAs,
From: Paul Colin Gloster <Colin_Paul_Gloster@ACM.org>
Date: Fri, 28 Dec 2012 10:23:45 +0000 (UTC)
Links: << >>  << T >>  << A >>
Do you support Ada?

Article: 154714
Subject: Re: Where to move for an embedded software engineer.
From: Paul Colin Gloster <Colin_Paul_Gloster@ACM.org>
Date: Fri, 28 Dec 2012 10:39:43 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2012-12-12, scrts <delete@myemail.com> sent:
|--------------------------------------------------------------------|
|[David Brown sent:]                                                 |
|["]And since the world extends a long way outside the USA, have you |
|considered moving abroad?  Certainly Norway has a great shortage of |
|engineers.["]                                                       |
|                                                                    |
|Really? Where can I search for job listings?"                       |
|--------------------------------------------------------------------|

It is not Norway but you can try:
WWW.EraCareers.Pt

Beware that the economy in Portugal is not excellent.

Good luck.

With kind regards,
Colin Paul Gloster

Article: 154715
Subject: Re: Where to move for an embedded software engineer.
From: Paul Colin Gloster <Colin_Paul_Gloster@ACM.org>
Date: Fri, 28 Dec 2012 10:54:00 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2012-12-17, David Brown <david@westcontrol.removethisbit.com>
sent:
|---------------------------------------------------------------------------|
|"[. . .]                                                                   |
|                                                                           |
|More importantly, you have to consider if you can live in the country      |
|you are looking at.  Language is a big issue.  In many technical           |
|departments of companies in Scandinavia, much of the work is in English.   |
|But towards the south of Europe, it is mostly in native languages          |
|(except in the bigger and more international companies).  Outside work,    |
|you can get by with English more easily in Northern Europe and smaller     |
|countries, but less so further south and in bigger countries.  A           |
|particular point here is that in countries like Norway or the              |
|Netherlands, much of the TV is foreign and in English with local           |
|subtitles - while in bigger countries like Spain and Italy, far more of    |
|the foreign TV is dubbed.  Similarly with books and translations.  This    |
|makes a big difference to how familiar people are with English in          |
|everyday life.                                                             |
|                                                                           |
|[. . .]"                                                                   |
|---------------------------------------------------------------------------|

Television is important, but not everybody uses
television. Soundtracks in Portugal are often in English but many
people in Portugal do not understand English, and this is at a similar
level to Italy where television is dubbed.

(A former colleague who spent most of her life in Italy improved her
English by using television in the Netherlands.)

Article: 154716
Subject: Re: Which to learn: Verilog vs. VHDL?
From: rickman <gnuarm@gmail.com>
Date: Fri, 28 Dec 2012 17:50:10 -0500
Links: << >>  << T >>  << A >>
On 12/28/2012 3:28 AM, joey899244@yahoo.cn wrote:
> it is all very fuzzy now. http://www.hqew.net/product-data/LM317T

I don't think there is any discussion that Verilog is easier to learn 
than VHDL.  As to which is the better language to learn is often 
debated.  I would say that the choice of language would depend on your 
goals for learning the language.  If you are doing hobby work, then you 
will have to choose yourself.  If you want to get work in the field, I 
would say learn both as there are lots of each, but most employers 
prefer one or the other.  I think if you learn VHDL first, Verilog will 
feel like a breath of fresh air... lol

That's my advice.  Meanwhile I am working with VHDL and have never put 
much effort into learning Verilog because I can't find a good book to 
use as a reference and learning guide.  I'm told none of the Verilog 
books are all that good.

There is also System Verilog and a number of other languages I  believe.

Rick

Article: 154717
Subject: Re: Which to learn: Verilog vs. VHDL?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 28 Dec 2012 23:23:11 +0000 (UTC)
Links: << >>  << T >>  << A >>
joey899244@yahoo.cn wrote:

> it is all very fuzzy now. http://www.hqew.net/product-data/LM317T

When I decided to learn verilog, I was told that C programmers find
verilog easier than VHDL. Still seems true to me.

For some time, the usual FPGA software had more support for
VHDL, but I think most now support both.

Also, for some time it seems that most ASIC work was done in verilog,
while more FPGA work done in VHDL. I don't know if that is still true.

I can usually read VHDL, but won't claim to be able to write it.

-- glen

Article: 154718
Subject: Re: Which to learn: Verilog vs. VHDL?
From: Tim Wescott <tim@seemywebsite.com>
Date: Fri, 28 Dec 2012 18:00:36 -0600
Links: << >>  << T >>  << A >>
On Fri, 28 Dec 2012 17:50:10 -0500, rickman wrote:

> On 12/28/2012 3:28 AM, joey899244@yahoo.cn wrote:
>> it is all very fuzzy now. http://www.hqew.net/product-data/LM317T
> 
> I don't think there is any discussion that Verilog is easier to learn
> than VHDL.  As to which is the better language to learn is often
> debated.  I would say that the choice of language would depend on your
> goals for learning the language.  If you are doing hobby work, then you
> will have to choose yourself.  If you want to get work in the field, I
> would say learn both as there are lots of each, but most employers
> prefer one or the other.  I think if you learn VHDL first, Verilog will
> feel like a breath of fresh air... lol
> 
> That's my advice.  Meanwhile I am working with VHDL and have never put
> much effort into learning Verilog because I can't find a good book to
> use as a reference and learning guide.  I'm told none of the Verilog
> books are all that good.
> 
> There is also System Verilog and a number of other languages I  believe.

I used Thomas & Moorby's "The Verilog Hardware Description Language", 
Fourth Edition.  It seemed to be OK.

Verilog vs. VHDL varies a lot by industry and region, as well as by 
company.  I chose Verilog because I live on the west coast, and most FPGA 
work around here is done in Verilog.  But the _second_ time I had to make 
money doing FPGA design, it was for an east coast company and they used 
VHDL.

So now I know both equally well.  (Or, more accurately, equally poorly).

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 154719
Subject: Chisel as alternative HDL
From: Martin Schoeberl <martin@jopdesign.com>
Date: Sat, 29 Dec 2012 00:06:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi all,

started to look into alternatives to Verilog and VHDL and
stumbled over chisel from UCB:
http://chisel.eecs.berkeley.edu/

Any experiences and comment on this language?

Looks like some challenge for me as it involves practically
learning 3 new languages at once: chisel itself, Scala on which
it is based, and Verilog, which is produced (I'm used to VHDL).

Cheers,
Martin

PS: I was *very* long absent from this group ;-)

Article: 154720
Subject: Re: Which to learn: Verilog vs. VHDL?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 29 Dec 2012 00:20:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.com> wrote:

(snip on verilog vs. VHDL)

> I used Thomas & Moorby's "The Verilog Hardware Description Language", 
> Fourth Edition.  It seemed to be OK.
 
> Verilog vs. VHDL varies a lot by industry and region, as well as by 
> company.  I chose Verilog because I live on the west coast, and most FPGA 
> work around here is done in Verilog.  But the _second_ time I had to make 
> money doing FPGA design, it was for an east coast company and they used 
> VHDL.
 
> So now I know both equally well.  (Or, more accurately, equally poorly).

For even more fun, use both in the same project. Even more, add in some
AHDL and schematic capture at the same time. (Yes, I did that once.)

-- glen

Article: 154721
Subject: Re: Chisel as alternative HDL
From: "garyr" <garyr@fidalgo.net>
Date: Fri, 28 Dec 2012 17:58:35 -0800
Links: << >>  << T >>  << A >>

"Martin Schoeberl" <martin@jopdesign.com> wrote in message
news:1621424063378432030.694310martin-jopdesign.com@reader.albasani.net...
> Hi all,
>
> started to look into alternatives to Verilog and VHDL and
> stumbled over chisel from UCB:
> http://chisel.eecs.berkeley.edu/
>
> Any experiences and comment on this language?
>
> Looks like some challenge for me as it involves practically
> learning 3 new languages at once: chisel itself, Scala on which
> it is based, and Verilog, which is produced (I'm used to VHDL).
>
> Cheers,
> Martin
>
> PS: I was *very* long absent from this group ;-)
>

You might find this interesting:  http://www.myhdl.org





Article: 154722
Subject: Re: Which to learn: Verilog vs. VHDL?
From: rickman <gnuarm@gmail.com>
Date: Fri, 28 Dec 2012 23:05:31 -0500
Links: << >>  << T >>  << A >>
On 12/28/2012 7:00 PM, Tim Wescott wrote:
> On Fri, 28 Dec 2012 17:50:10 -0500, rickman wrote:
>
>> On 12/28/2012 3:28 AM, joey899244@yahoo.cn wrote:
>>> it is all very fuzzy now. http://www.hqew.net/product-data/LM317T
>>
>> I don't think there is any discussion that Verilog is easier to learn
>> than VHDL.  As to which is the better language to learn is often
>> debated.  I would say that the choice of language would depend on your
>> goals for learning the language.  If you are doing hobby work, then you
>> will have to choose yourself.  If you want to get work in the field, I
>> would say learn both as there are lots of each, but most employers
>> prefer one or the other.  I think if you learn VHDL first, Verilog will
>> feel like a breath of fresh air... lol
>>
>> That's my advice.  Meanwhile I am working with VHDL and have never put
>> much effort into learning Verilog because I can't find a good book to
>> use as a reference and learning guide.  I'm told none of the Verilog
>> books are all that good.
>>
>> There is also System Verilog and a number of other languages I  believe.
>
> I used Thomas&  Moorby's "The Verilog Hardware Description Language",
> Fourth Edition.  It seemed to be OK.

I'm not sure how good "ok" is I guess.  I asked in the Verilog group for 
recommendations for a good book and several told me there were no "good" 
Verilog books.  I should pick up a good Verilog book sometime.  The only 
thing I have is a book that covers both VHDL and Verilog with many 
examples done in both languages.  I can't recall the name and I'm not 
sure the book is here at the moment.  One of the problems of having dual 
(or is it trinary) residency.  I expect my next text book will be an 
e-copy if I can get it without locking to hardware.  How does that work 
exactly?


> Verilog vs. VHDL varies a lot by industry and region, as well as by
> company.  I chose Verilog because I live on the west coast, and most FPGA
> work around here is done in Verilog.  But the _second_ time I had to make
> money doing FPGA design, it was for an east coast company and they used
> VHDL.
>
> So now I know both equally well.  (Or, more accurately, equally poorly).

Yes, I did some work for a networking company once.  I did my code in 
VHDL which they didn't mind since it was a self contained board.  But 
all of their work was Verilog which I got to see.  I found it less well 
documented and much poorer use of white space and formatting.  But much 
of that is just what you are used to I'm sure.  I don't think they 
suffered any great loss of productivity.

I believe there have been a few competitions where Verilog was shown to 
be a bit more productive in banging out code you can do in a few hours. 
  This is not the end all, be all of language comparisons however.  I'm 
sure the long term costs of writing code are not completely correlated 
to how quickly a few hundred lines of code can be written and debugged.

Rick

Article: 154723
Subject: Re: Chisel as alternative HDL
From: Martin Schoeberl <martin@jopdesign.com>
Date: Sat, 29 Dec 2012 05:25:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
"garyr" <garyr@fidalgo.net> wrote:
> "Martin Schoeberl" <martin@jopdesign.com> wrote in message
> news:1621424063378432030.694310martin-jopdesign.com@reader.albasani.net...
>> Hi all,
>> 
>> started to look into alternatives to Verilog and VHDL and
>> stumbled over chisel from UCB:
>> http://chisel.eecs.berkeley.edu/
>> 
>> Any experiences and comment on this language?
>> 
>> Looks like some challenge for me as it involves practically
>> learning 3 new languages at once: chisel itself, Scala on which
>> it is based, and Verilog, which is produced (I'm used to VHDL).
>> 
>> Cheers,
>> Martin
>> 
>> PS: I was *very* long absent from this group ;-)
>> 
> 
> You might find this interesting:  http://www.myhdl.org

Thanks for pointing this out, although it was not the 'real' answer to
my question ;-)

I'm already looking at MyHDL and some other projects. chisel just lookes
most promising at the moment. Maybe I change my mind.

A good comparison would be to do one HW design, e.g. a standard MIPS
pipeline, in all languages and compare the efficiency of the language and
the efficiency of the resulting HW implementation.

Martin

Article: 154724
Subject: Re: Where to move for an embedded software engineer.
From: Paul Colin Gloster <Colin_Paul_Gloster@ACM.org>
Date: Sat, 29 Dec 2012 16:23:09 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 12/12/2012, Tim Wescott sent:
|--------------------------------------------------------------------------|
|"[. . .]                                                                  |
|                                                                          |
|Pay close attention to cost of living: I had a friend from the Portland   |
|(OR) area who went to work at a company in Silicon Valley at a pay rate   |
|that astonished him, only to discover after he had moved that the cost of |
|rent and food and damn near everything else is astonishing, too -- he     |
|soon found a gig in Seattle for way less pay and higher net return.  This |
|cuts both ways: a pay rate that sucks in Portland (and is in the sub-     |
|basements in San Jose) may get you ahead in the long run if the job is in |
|Missoula.                                                                 |
|                                                                          |
|[. . .]"                                                                  |
|--------------------------------------------------------------------------|

Do not be conned into a bad-faith contract to provide assistance
finding somewhere affordable to live:

HTTP://69.54.212.166/~gloster/Evil_which_is_so-called_science/Mariano_Gago/Attachment_emailed_to_Gago_during_August_2012.htm



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