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 160150

Article: 160150
Subject: Re: VHDL or Verilog?
From: lasselangwadtchristensen@gmail.com
Date: Wed, 21 Jun 2017 14:05:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin:
> I've been given conflicting device on which language to use.  There
> are people I would consider to be expert professionals who tell me
> to use VHDL, and others who tell me Verilog.  Most everybody tells
> me that if I use VHDL there's less chance for error, but that it
> does take more effort to learn.
> 
> Any thoughts?
> 

don't you already have enough arguments over religion? ;)




Article: 160151
Subject: Re: VHDL or Verilog?
From: rickman <gnuarm@gmail.com>
Date: Wed, 21 Jun 2017 17:17:22 -0400
Links: << >>  << T >>  << A >>
lasselangwadtchristensen@gmail.com wrote on 6/21/2017 5:05 PM:
> Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin:
>> I've been given conflicting device on which language to use.  There
>> are people I would consider to be expert professionals who tell me
>> to use VHDL, and others who tell me Verilog.  Most everybody tells
>> me that if I use VHDL there's less chance for error, but that it
>> does take more effort to learn.
>>
>> Any thoughts?
>>
>
> don't you already have enough arguments over religion? ;)

I feel that is uncalled for.  When he comes here proselytizing then respond 
about that (or better ignore him).  But when he comes here like the rest of 
us asking for technical help, why pick on him?

-- 

Rick C

Article: 160152
Subject: Re: VHDL or Verilog?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 21 Jun 2017 14:27:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, June 21, 2017 at 5:05:50 PM UTC-4, lasselangwad...@gmail.com wrote:
> Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin:
> > I've been given conflicting device on which language to use.  There
> > are people I would consider to be expert professionals who tell me
> > to use VHDL, and others who tell me Verilog.  Most everybody tells
> > me that if I use VHDL there's less chance for error, but that it
> > does take more effort to learn.
> > 
> > Any thoughts?
> 
> don't you already have enough arguments over religion? ;)

LOL!  I didn't know.  I plea ignorance.

Thank you,
Rick C. Hodgin

Article: 160153
Subject: Re: VHDL or Verilog?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 21 Jun 2017 14:28:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, June 21, 2017 at 5:17:24 PM UTC-4, rickman wrote:
> lasselangwadtchristensen@gmail.com wrote on 6/21/2017 5:05 PM:
> > Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin:
> >> I've been given conflicting device on which language to use.  There
> >> are people I would consider to be expert professionals who tell me
> >> to use VHDL, and others who tell me Verilog.  Most everybody tells
> >> me that if I use VHDL there's less chance for error, but that it
> >> does take more effort to learn.
> >>
> >> Any thoughts?
> >>
> >
> > don't you already have enough arguments over religion? ;)
> 
> I feel that is uncalled for.  When he comes here proselytizing then respond 
> about that (or better ignore him).  But when he comes here like the rest of 
> us asking for technical help, why pick on him?

It's okay.  I thought it was very funny actually.  I couldn't
respond more timely though because I was at a stop light when
I read it. :-)

Thank you,
Rick C. Hodgin

Article: 160154
Subject: Re: VHDL or Verilog?
From: rickman <gnuarm@gmail.com>
Date: Wed, 21 Jun 2017 17:31:46 -0400
Links: << >>  << T >>  << A >>
Rick C. Hodgin wrote on 6/21/2017 5:28 PM:
> On Wednesday, June 21, 2017 at 5:17:24 PM UTC-4, rickman wrote:
>> lasselangwadtchristensen@gmail.com wrote on 6/21/2017 5:05 PM:
>>> Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin:
>>>> I've been given conflicting device on which language to use.  There
>>>> are people I would consider to be expert professionals who tell me
>>>> to use VHDL, and others who tell me Verilog.  Most everybody tells
>>>> me that if I use VHDL there's less chance for error, but that it
>>>> does take more effort to learn.
>>>>
>>>> Any thoughts?
>>>>
>>>
>>> don't you already have enough arguments over religion? ;)
>>
>> I feel that is uncalled for.  When he comes here proselytizing then respond
>> about that (or better ignore him).  But when he comes here like the rest of
>> us asking for technical help, why pick on him?
>
> It's okay.  I thought it was very funny actually.  I couldn't
> respond more timely though because I was at a stop light when
> I read it. :-)

Actually I guess it was rather a joke instead of an insult.  I didn't pick 
up on that.  VHDL vs. Verilog can very much be a religious war.

Sorry Lasse.

-- 

Rick C

Article: 160155
Subject: Re: VHDL or Verilog?
From: lasselangwadtchristensen@gmail.com
Date: Wed, 21 Jun 2017 14:42:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den onsdag den 21. juni 2017 kl. 23.17.24 UTC+2 skrev rickman:
> lasselangwadtchristensen@gmail.com wrote on 6/21/2017 5:05 PM:
> > Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin:
> >> I've been given conflicting device on which language to use.  There
> >> are people I would consider to be expert professionals who tell me
> >> to use VHDL, and others who tell me Verilog.  Most everybody tells
> >> me that if I use VHDL there's less chance for error, but that it
> >> does take more effort to learn.
> >>
> >> Any thoughts?
> >>
> >
> > don't you already have enough arguments over religion? ;)
> 
> I feel that is uncalled for.  When he comes here proselytizing then respond 
> about that (or better ignore him).  But when he comes here like the rest of 
> us asking for technical help, why pick on him?

if you think is was picking on him that's on you, it was meant as a 
tongue-in-cheeck comment that asking whether you should use verilog or vhdl
is probably going to end like asking what religion is best catholic or protestant. Everyone has a set opinion and soon someone will say you shouldn't
be either and be atheist instead  





Article: 160156
Subject: Re: VHDL or Verilog?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 21 Jun 2017 14:51:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, June 21, 2017 at 5:42:40 PM UTC-4, lasselangwad...@gmail.com wrote:
> Den onsdag den 21. juni 2017 kl. 23.17.24 UTC+2 skrev rickman:
> > lasselangwadtchristensen@gmail.com wrote on 6/21/2017 5:05 PM:
> > > Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin:
> > >> I've been given conflicting device on which language to use.  There
> > >> are people I would consider to be expert professionals who tell me
> > >> to use VHDL, and others who tell me Verilog.  Most everybody tells
> > >> me that if I use VHDL there's less chance for error, but that it
> > >> does take more effort to learn.
> > >>
> > >> Any thoughts?
> > >>
> > >
> > > don't you already have enough arguments over religion? ;)
> > 
> > I feel that is uncalled for.  When he comes here proselytizing then respond 
> > about that (or better ignore him).  But when he comes here like the rest of 
> > us asking for technical help, why pick on him?
> 
> if you think is was picking on him that's on you, it was meant as a 
> tongue-in-cheeck comment that asking whether you should use verilog or vhdl
> is probably going to end like asking what religion is best catholic or protestant. Everyone has a set opinion and soon someone will say you shouldn't
> be either and be atheist instead

Just so everybody's clear also ... I enjoy working with people, and
sharing in our technical expertise.  My posts about salvation and
forgiveness of sin are given because of what's happened in my life.

I'm currently part of a group of people who are from all backgrounds
and interests, with some of them overlapping into the same hardware
and software areas I'm interested in.

As such, it's a very powerful and diverse group of people.  It's the
thing I enjoy ... helping, sharing, expressing, in these areas.  We
are together a more diverse and capable group than we are in iso-
lation.

Thank you,
Rick C. Hodgin

Article: 160157
Subject: Re: VHDL or Verilog?
From: Jim Lewis <usevhdl@gmail.com>
Date: Wed, 21 Jun 2017 16:11:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rick,
Most of the hard things related to conversions and types are summarized in:
http://synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf

Cheers,
Jim

Article: 160158
Subject: Re: VHDL or Verilog?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 21 Jun 2017 18:24:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
Jim Lewis wrote:
> Rick, Most of the hard things related to conversions and
> types are summarized in:
>     http://synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf
>
> Cheers, Jim

Thanks, Jim.  I'll check it out.

Thank you,
Rick C. Hodgin

Article: 160159
Subject: Re: VHDL or Verilog?
From: Lars Brinkhoff <lars.spam@nocrew.org>
Date: Thu, 22 Jun 2017 07:11:04 +0200
Links: << >>  << T >>  << A >>
Rick C. Hodgin wrote:
> I've been given conflicting device on which language to use.  There
> are people I would consider to be expert professionals who tell me
> to use VHDL, and others who tell me Verilog.

Here's an article on that:

https://www.nandland.com/articles/vhdl-or-verilog-for-fpga-asic.html

Article: 160160
Subject: Re: VHDL or Verilog?
From: David Brown <david.brown@hesbynett.no>
Date: Thu, 22 Jun 2017 11:12:58 +0200
Links: << >>  << T >>  << A >>
On 21/06/17 14:08, Rick C. Hodgin wrote:
> I've been given conflicting device on which language to use.  There
> are people I would consider to be expert professionals who tell me
> to use VHDL, and others who tell me Verilog.  Most everybody tells
> me that if I use VHDL there's less chance for error, but that it
> does take more effort to learn.
> 
> Any thoughts?
> 

Have you considered other possibilities?  VHDL and Verilog are the two
main HDL languages, but they are far from the only choices.  There are
many others, most of which give different ways to express the logic that
at least some people consider clearer, less error-prone, or more
productive.  Usually these other tools include different ways to test or
simulate the logic, and generate VHDL and/or Verilog output for
synthesis with FPGA tools.

Note that it is quite a while since I have done any FPGA designs, so my
comments here are based on things I did many years ago, or things I have
read about and learned about but not used in practice.  So if anyone
else has direct experience here, their comments would be valuable.  But
certainly if I were to start working on a new FPGA project, I would look
much wider than Verilog or VHDL before deciding on the tools for the job.

An obvious step up from Verilog is SystemVerilog.  It gives a bit more
structure to interfaces, has a few more types, and has different
"always" blocks that reduce the risk of accidentally generating the
wrong type of logic.  It also has many new non-synthesizable features
for making better simulation testbenches.

Handel-C is an HDL that is a superset of C.  It adds features such as
parallel and sequential blocks, channels for communication between
parallel threads, and HDL concepts such as reset, clocks, etc.

MyHDL is a popular Python-based HDL.  Since it is Python, you have a lot
of freedom and flexibility that you might not get in a lower level HDL.
 It also means that your main testbench code can also be written
directly in Python.


Personally, I used Confluence a long time ago.  This was a functional
programming language HDL.  However, the tool was very much a one-man
project, and when he decided to move on to other things, the project
disappeared - there was never a serious community around it.  But I
found the language let me write much smaller and simpler code, with
fewer problems and shorter test/debug cycles, compared to Verilog.

A big question in this is what sort of designs do you want to make?  One
concept that I like is higher level generators.  For example, consider
making peripherals that are memory mapped on a bus.  Your peripherals
will have some registers that can be read or written from the bus, and
logic to actually /do/ something with the register values (such as a
timer, a UART interface, or whatever).

The bus interface part has a similar structure - you have a list of
registers, information about their sizes, their offsets from the base
address, their read/write capabilities.  You have an address decoder for
the bus, and a bus slave interface that depends on the bus protocol.

You can write such a bus interface in straight Verilog or VHDL.  And
once you have made an interface component for a UART, you can use it
repeatedly for as many UARTs as you want.  But when you want to make the
interface for a timer peripheral, it is copy-and-paste and then you
modify it for the new peripheral.  And so on.  VHDL generics might allow
you a little more re-usability, but my understanding is that the
implementation of them in existing tools is very limited.

But in a higher level HDL, you can write a bus interface generator - a
function or component that takes a list of registers and their details,
and generates an instance of an interface.  So once that generator is
written, you can use it for all your different peripherals.




Article: 160161
Subject: Re: FPGA input pin connection to receive MIPI CSI-2
From: abirov@gmail.com
Date: Thu, 22 Jun 2017 05:33:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, July 13, 2011 at 7:27:03 AM UTC+6, aisitei wrote:
> Hi.
> I'm just beginner in making fpga
> and i want to make MIPI CSI-2 to parallel converter in fpga.
> 
> i think there are strange point.
> in mipi spec, there are two mode, LP and HS mode, and these are very
> different.
> 
> how can i connect mipi p/n pins to fpga?

Use this :
https://github.com/daveshah1/CSI2Rx

Article: 160162
Subject: Re: VHDL or Verilog?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 22 Jun 2017 07:11:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, June 22, 2017 at 5:13:02 AM UTC-4, David Brown wrote:
> On 21/06/17 14:08, Rick C. Hodgin wrote:
> > I've been given conflicting device on which language to use.  There
> > are people I would consider to be expert professionals who tell me
> > to use VHDL, and others who tell me Verilog.  Most everybody tells
> > me that if I use VHDL there's less chance for error, but that it
> > does take more effort to learn.
> > 
> > Any thoughts?
> 
> Have you considered other possibilities?  VHDL and Verilog are the two
> main HDL languages, but they are far from the only choices...

Thank you for your guidance, David.  Your input is appreciated.

Thank you,
Rick C. Hodgin

Article: 160163
Subject: Re: VHDL or Verilog?
From: Rob Gaddi <rgaddi@highlandtechnology.invalid>
Date: Thu, 22 Jun 2017 08:59:53 -0700
Links: << >>  << T >>  << A >>
On 06/22/2017 02:12 AM, David Brown wrote:

> You can write such a bus interface in straight Verilog or VHDL.  And
> once you have made an interface component for a UART, you can use it
> repeatedly for as many UARTs as you want.  But when you want to make the
> interface for a timer peripheral, it is copy-and-paste and then you
> modify it for the new peripheral.  And so on.  VHDL generics might allow
> you a little more re-usability, but my understanding is that the
> implementation of them in existing tools is very limited.
> 
> But in a higher level HDL, you can write a bus interface generator - a
> function or component that takes a list of registers and their details,
> and generates an instance of an interface.  So once that generator is
> written, you can use it for all your different peripherals.
> 

That's actually one of the features going into VHDL-2017, is the concept 
of higher level interfaces.  So you'll be able to bring in an AXI 
package, say that an entity has a AXI interface port, and control the 
bus logic with a couple functions from that package without having to 
cut and paste all that boilerplate.

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

Article: 160164
Subject: Re: VHDL or Verilog?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 22 Jun 2017 11:10:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, June 22, 2017 at 5:13:02 AM UTC-4, David Brown wrote:
> Have you considered other possibilities?  VHDL and Verilog are the two
> main HDL languages, but they are far from the only choices...

To provide a little more detail, I know I've told you before that
I am going to author the Logician tool, which will allow a Blender
nodes-like ability to manipulate objects graphically, and to move
them in 3D space using OpenGL.

-----
I am a very visual person, and I have a hard time reading, and
despite my profession, that actually includes software code as
well.  I prefer to draw things on white boards, on paper, to
have symbols used instead of words for things, etc.  Also,
you've commented before on my unusual spacing in source files,
but I do that because another part of my brain is responsible
for organizing things geometrically, which relieves pressure on
my reading centers, making it easier for me to read.

So, my goals are to learn VHDL or Verilog, and then author the
Logician tool, and then have it translate the visual definition
of that tool into the VHDL or Verilog syntax language for use in
traditional tools.  I do not plan to remain in VHDL or Verilog
for very long.

And for my immediate need, I'm getting conflicting guidance from
the group I've recently become involved with, and I just wanted
some advice from the FPGA group here.  For the time being, I'll
be using Arduino to get my product working while I continue to
devote time to learning my Altera or Lattice FPGA toolkits in
the evenings and weekends.

-----
To all:  I could use some assistance in working with Altera's
         Quartus on a Cyclone V GX Starter Kit, or Lattice's
         Diamond on an ECP5.

Thank you,
Rick C. Hodgin

Article: 160165
Subject: Re: VHDL or Verilog?
From: "Michael Kellett" <nospam@invalid.com>
Date: fri, 23 jun 2017 09:02:09 +0100
Links: << >>  << T >>  << A >>
Rick C. Hodgin:
> On Thursday, June 22, 2017 at 5:13:02 AM UTC-4, David Brown wrote:
>> Have you considered other possibilities?  VHDL and Verilog are the
two
>> main HDL languages, but they are far from the only choices...
> 
> To provide a little more detail, I know I've told you before that
> I am going to author the Logician tool, which will allow a Blender
> nodes-like ability to manipulate objects graphically, and to move
> them in 3D space using OpenGL.
> 
> -----
> I am a very visual person, and I have a hard time reading, and
> despite my profession, that actually includes software code as
> well.  I prefer to draw things on white boards, on paper, to
> have symbols used instead of words for things, etc.  Also,
> you've commented before on my unusual spacing in source files,
> but I do that because another part of my brain is responsible
> for organizing things geometrically, which relieves pressure on
> my reading centers, making it easier for me to read.
> 
> So, my goals are to learn VHDL or Verilog, and then author the
> Logician tool, and then have it translate the visual definition
> of that tool into the VHDL or Verilog syntax language for use in
> traditional tools.  I do not plan to remain in VHDL or Verilog
> for very long.
> 
> And for my immediate need, I'm getting conflicting guidance from
> the group I've recently become involved with, and I just wanted
> some advice from the FPGA group here.  For the time being, I'll
> be using Arduino to get my product working while I continue to
> devote time to learning my Altera or Lattice FPGA toolkits in
> the evenings and weekends.
> 
> -----
> To all:  I could use some assistance in working with Altera's
>          Quartus on a Cyclone V GX Starter Kit, or Lattice's
>          Diamond on an ECP5.
> 
> Thank you,
> Rick C. Hodgin

Visual or graphic entry design tools for HDLs are somewhat out of favour
at the moment. (But not with me !) The only serious one I know (and use
every day) is the Block Diagram Editor in Aldec-HDL. If you want  a tool
just to use you can buy that (Aldec-HDL Desktop edition) for about
£1600. If you want to create your own tool you will need some helpers -
it's more than a one man job.
There is  a tool in Vivado but it's not really the same kind of thing.
I find the ability to describe a complex project with hierarchical block
diagrams to be very useful. Since the VHDl (or Verilog) is generated
from the diagrams you get customer friendly documentation that is
actually up to date !

MK

Article: 160166
Subject: Re: VHDL or Verilog?
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 23 Jun 2017 05:39:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, June 23, 2017 at 4:04:57 AM UTC-4, Michael Kellett wrote:
> Rick C. Hodgin:
> > On Thursday, June 22, 2017 at 5:13:02 AM UTC-4, David Brown wrote:
> >> Have you considered other possibilities?  VHDL and Verilog are the
> two
> >> main HDL languages, but they are far from the only choices...
> >=20
> > To provide a little more detail, I know I've told you before that
> > I am going to author the Logician tool, which will allow a Blender
> > nodes-like ability to manipulate objects graphically, and to move
> > them in 3D space using OpenGL.
> >=20
> > -----
> > I am a very visual person, and I have a hard time reading, and
> > despite my profession, that actually includes software code as
> > well.  I prefer to draw things on white boards, on paper, to
> > have symbols used instead of words for things, etc.  Also,
> > you've commented before on my unusual spacing in source files,
> > but I do that because another part of my brain is responsible
> > for organizing things geometrically, which relieves pressure on
> > my reading centers, making it easier for me to read.
> >=20
> > So, my goals are to learn VHDL or Verilog, and then author the
> > Logician tool, and then have it translate the visual definition
> > of that tool into the VHDL or Verilog syntax language for use in
> > traditional tools.  I do not plan to remain in VHDL or Verilog
> > for very long.
> >=20
> > And for my immediate need, I'm getting conflicting guidance from
> > the group I've recently become involved with, and I just wanted
> > some advice from the FPGA group here.  For the time being, I'll
> > be using Arduino to get my product working while I continue to
> > devote time to learning my Altera or Lattice FPGA toolkits in
> > the evenings and weekends.
> >=20
> > -----
> > To all:  I could use some assistance in working with Altera's
> >          Quartus on a Cyclone V GX Starter Kit, or Lattice's
> >          Diamond on an ECP5.
> >=20
> > Thank you,
> > Rick C. Hodgin
>=20
> Visual or graphic entry design tools for HDLs are somewhat out of favour
> at the moment. (But not with me !) The only serious one I know (and use
> every day) is the Block Diagram Editor in Aldec-HDL. If you want  a tool
> just to use you can buy that (Aldec-HDL Desktop edition) for about
> =C5=811600.

I'd be curious to see how it looks.  I plan on mine being basically
this simple:

    Note:  I have not listened to the audio on this video, but
           muted it and looked at the nodes illustration.

    https://www.youtube.com/watch?v=3DHro1BIWFEDQ&t=3D1m38s

> If you want to create your own tool you will need some helpers -
> it's more than a one man job.

I'll be sure to ask for helpers on the project. :-)

> There is  a tool in Vivado but it's not really the same kind of thing.
> I find the ability to describe a complex project with hierarchical block
> diagrams to be very useful. Since the VHDl (or Verilog) is generated
> from the diagrams you get customer friendly documentation that is
> actually up to date !

I know when I sit down to think things through, it goes so much more
easily for me to think in concepts than in mechanics.  I think the
visual tool will allow me to both.

But, I have several steps ahead of Logician in line:

    Visual FreePro, Jr.
    RDC and CAlive (compiler framework and C-like compiler)
    Visual FreePro (full version)
    ES/2 operating system (an open source OS/2 clone)
    Logician
    My various hardware designs

My long-term vision for completing these things are through
2025 if I can find revenue to allow me to devote my day labor
hours to these projects, and some help.  Otherwise, it will
be a remainder-of-my-life kind of thing (I'm 47 now).

Thank you,
Rick C. Hodgin

Article: 160167
Subject: consulting job / Xilinx Artix MGT POR
From: Tobias Kahre <tobias.kahre@epb-dienstleistungen.de>
Date: Mon, 26 Jun 2017 17:19:50 +0200
Links: << >>  << T >>  << A >>
Hi there,

I am looking for an expert on how to by-hand-configure MGTs individually of an single quad.
I have an Artix 35T, the first MGT has to do aurora, the second and third one has to do JESD204b.

I am offering a consulting fee for teaching me personally and/or working design of POR up to exchange of comma characters.

Cheers, 
Tobias

Article: 160168
Subject: Re: Article about using Non-Project Mode
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 30 Jun 2017 14:15:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
> I'll publish the article as soon as it is reviewed by my employer.
>=20
> Kevin, if you have an Google account you can request access to the draft =
and I'll grant it to you.

Ilya,
Thanks for the document.  You inspired me to use non-project mode and now t=
hat I have a script for one of my projects I can just keep reusing it.  The=
 only thing I'd say about your document is that I think it had some Windows=
-specific stuff which wasn't obvious to me at first.

There is also a brief intro to non-project mode in the Vivado Quick Referen=
ce:

http://tinyurl.com/yb9d8y8d

Article: 160169
Subject: converting from Xilinx 9500 to 9500XL, won't fit
From: Jon Elson <elson@pico-systems.com>
Date: Thu, 13 Jul 2017 22:15:37 -0500
Links: << >>  << T >>  << A >>
Hello, all,

I have an old design implemented in the Xilinx 9572, and need to update it.  
Using ise 13.4, I created a new project, imported the files, and found it 
won't fit in the 9572XL, which was a big surprise.  Although the 9572 was 
fairly full, the design easily fit there, and I just recompiled it for the 
9572, and this version of ise easily fit it.

Does anybody have any suggestions on settings to make it fit in the XL?

The error messages suggest reducing the collapsing input limit or the 
product term limit.  I did this in the Design goals and Strategies, but at 
the end of the fitter report it still shows the default values.  Is there a 
trick to making it use the modified limits and other options?

Not only does the 95144XL cost a bit more, but it is only available in the 
next size up package.

Thanks very much for any help.

Jon

Article: 160170
Subject: Re: converting from Xilinx 9500 to 9500XL, won't fit
From: Jon Elson <elson@pico-systems.com>
Date: Thu, 13 Jul 2017 23:05:41 -0500
Links: << >>  << T >>  << A >>
Jon Elson wrote:

> Hello, all,
> 
> I have an old design implemented in the Xilinx 9572, and need to update
> it. Using ise 13.4, I created a new project, imported the files, and found
> it
> won't fit in the 9572XL, which was a big surprise.  Although the 9572 was
> fairly full, the design easily fit there, and I just recompiled it for the
> 9572, and this version of ise easily fit it.
> 
Ah, I found that the REAL place you set the options is right clicking the 
fit button then properties.  With a little adjustment of parameters, it did 
fit, but seems to use a little more resources than on the 9500.  But, I have 
to add 2 signals to the state machine to control an external bi-directional 
level translator, so with it so close to the limit, I think it will be 
necessary to move up to the 95144XL part.

Jon

Article: 160171
Subject: IP core LCD controller for Zynq-7000 famiy
From: ucy193@gmail.com
Date: Thu, 20 Jul 2017 10:39:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Do you know something about free IP cores for this fpga?
Xylon IPs are too expensive for me.


Cheers,
ucy

Article: 160172
Subject: Re: converting from Xilinx 9500 to 9500XL, won't fit
From: Rob Gaddi <rgaddi@highlandtechnology.invalid>
Date: Fri, 21 Jul 2017 08:14:27 -0700
Links: << >>  << T >>  << A >>
On 07/13/2017 09:05 PM, Jon Elson wrote:
> Jon Elson wrote:
> 
>> Hello, all,
>>
>> I have an old design implemented in the Xilinx 9572, and need to update
>> it. Using ise 13.4, I created a new project, imported the files, and found
>> it
>> won't fit in the 9572XL, which was a big surprise.  Although the 9572 was
>> fairly full, the design easily fit there, and I just recompiled it for the
>> 9572, and this version of ise easily fit it.
>>
> Ah, I found that the REAL place you set the options is right clicking the
> fit button then properties.  With a little adjustment of parameters, it did
> fit, but seems to use a little more resources than on the 9500.  But, I have
> to add 2 signals to the state machine to control an external bi-directional
> level translator, so with it so close to the limit, I think it will be
> necessary to move up to the 95144XL part.
> 
> Jon
> 

The one thing I'd mention is, have you tried comparing the 
portion-by-portion resource usage breakdowns between the 9572 and 9572XL 
builds?  It may be there was one section of the design that the 
synthesizer got confused about in the XL and blew up.

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

Article: 160173
Subject: sram
From: kristoff <kristoff@skypro.be>
Date: Sat, 22 Jul 2017 19:52:38 +0200
Links: << >>  << T >>  << A >>
Hi,


OK, left the lora chips asside for a while, so .. now back to FPGAs.

I have two olimex ice40 boards where I would like to use the onboard 
SRAM. The RAM chip is a samsung K5R4016V1B-10 (256K words * 16 bits).

The datasheets are here:
https://www.olimex.com/Products/_resources/ds_k6r4016v1d_rev40.pdf
The most important pages are page 7 (for "read"), pages 8 and 9 (for 
"write") and page 10 (for the functional description of the pins).


I am trying to interprete the datasheets to see how to use the chip. I 
think I understand how to read or write one word, but I still puzzled on 
how to do bulk-write transfers


* For read, it seams to be simple:
set /WE high and  /OE low (*)

1/ put the address on the address-bus
2/ 10 ns later, read the data from the data-out
(*) ignoring the /CS, /LB and /UB pins to keep things simple.

In bulk transfer, it is like this:
- set address 1 on the Address bus
- 10 ns later:
-> read the data of address 1 from data-out
-> (at the same time) set address 2 on the address bus
- 10 bs later:
-> read the data of address 2 from data-out
-> (at the same time) set address 3 on the address bus
(etc)


* For write, to write one single word, I think it goes like this

1/ set /WE low and /OE high to go to "write" mode
-> at the same time set te address on the address bus
-> do not yet put the data on the databus (as it still in "output" mode)
2/ 10 ns later:
-> put the data on the data-bus (by then, the data-bus has switched to 
"data-in"
3/ another 10 ns later:
-> set /WE high and /OE low to leave "write" mode

But I am still puzzled on how to do a "bulk write" of data. The 
datasheets do not mention anything on what happens if leave the chip in 
"write" mode and just change the address on the address-bus (as is done 
for bulk-read)

It there is no seperate bulk-write protocol, it looks like a write to 
the chip takes 3 times as much steps then a bulk-read (3 steps compaired 
to one single step).


Is this a correct interpretation of the datasheet?

Can somebody who has already interfaced an FPGA with SRAM confirm or 
deny this. Or is there another trick on how to do a bulk-write on a SRAM 
chip?




Cheerio! Kr. Bonne.

Article: 160174
Subject: Re: sram
From: Cecil Bayona <cbayona@cbayona.com>
Date: Sat, 22 Jul 2017 13:19:25 -0500
Links: << >>  << T >>  << A >>
Static RAM chips do not have bulk mode, it's not needed, you write to it 
one word at a time. Its EEPROM, FLASH, and similar memory with it's 
complicated setup that are  in need of bulk mode as they are slow and 
bulk mode is faster, some only have bulk mode.


On 7/22/2017 12:52 PM, kristoff wrote:
> Hi,
> 
> 
> OK, left the lora chips asside for a while, so .. now back to FPGAs.
> 
> I have two olimex ice40 boards where I would like to use the onboard 
> SRAM. The RAM chip is a samsung K5R4016V1B-10 (256K words * 16 bits).
> 
> The datasheets are here:
> https://www.olimex.com/Products/_resources/ds_k6r4016v1d_rev40.pdf
> The most important pages are page 7 (for "read"), pages 8 and 9 (for 
> "write") and page 10 (for the functional description of the pins).
> 
> 
> I am trying to interprete the datasheets to see how to use the chip. I 
> think I understand how to read or write one word, but I still puzzled on 
> how to do bulk-write transfers
> 
> 
> * For read, it seams to be simple:
> set /WE high and  /OE low (*)
> 
> 1/ put the address on the address-bus
> 2/ 10 ns later, read the data from the data-out
> (*) ignoring the /CS, /LB and /UB pins to keep things simple.
> 
> In bulk transfer, it is like this:
> - set address 1 on the Address bus
> - 10 ns later:
> -> read the data of address 1 from data-out
> -> (at the same time) set address 2 on the address bus
> - 10 bs later:
> -> read the data of address 2 from data-out
> -> (at the same time) set address 3 on the address bus
> (etc)
> 
> 
> * For write, to write one single word, I think it goes like this
> 
> 1/ set /WE low and /OE high to go to "write" mode
> -> at the same time set te address on the address bus
> -> do not yet put the data on the databus (as it still in "output" mode)
> 2/ 10 ns later:
> -> put the data on the data-bus (by then, the data-bus has switched to 
> "data-in"
> 3/ another 10 ns later:
> -> set /WE high and /OE low to leave "write" mode
> 
> But I am still puzzled on how to do a "bulk write" of data. The 
> datasheets do not mention anything on what happens if leave the chip in 
> "write" mode and just change the address on the address-bus (as is done 
> for bulk-read)
> 
> It there is no seperate bulk-write protocol, it looks like a write to 
> the chip takes 3 times as much steps then a bulk-read (3 steps compaired 
> to one single step).
> 
> 
> Is this a correct interpretation of the datasheet?
> 
> Can somebody who has already interfaced an FPGA with SRAM confirm or 
> deny this. Or is there another trick on how to do a bulk-write on a SRAM 
> chip?
> 
> 
> 
> 
> Cheerio! Kr. Bonne.


-- 
Cecil - k5nwa



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