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
2017JanFebMarApr2017

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 159525

Article: 159525
Subject: Re: Phrasing!
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 2 Dec 2016 03:32:16 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, December 2, 2016 at 3:10:19 AM UTC-5, o pere o wrote:
>=20
> This is a point, although a weak one. The same should also happen to the=
=20
> microcontroller industry... but does not. They are quite happy selling=20
> chips that are being programmed by the open-sourced gcc toolchain.
>=20
Also consider that on the gcc side of things that they have a lot of people=
 who know how to write software that are writing and developing the gcc sof=
tware.  There aren't nearly as many people who know how to write software w=
orking on software stuff for hardware like FPGAs.  Witness that we don't ha=
ve much of anything other than GHDL as a basic simulator.  Development on t=
hat is up to the whims of one person who chooses to work on it (or not in w=
hich case everything stops...as it has of late).

It wouldn't surprise me if FPGA companies probably consider that the open s=
ource community would take forever to develop anything.

Kevin

Article: 159526
Subject: Re: SD card emulation
From: rickman <gnuarm@gmail.com>
Date: Fri, 2 Dec 2016 06:55:41 -0500
Links: << >>  << T >>  << A >>
On 12/2/2016 2:04 AM, Sri G wrote:
> I stumbled on that project but its almost 10 years old! Nevertheless,
> I reached out to Antti Luktas, hopefully he's not too busy to get
> back to me :)
>
> Making the physical connection isn't too difficult:
> https://www.amazon.com/48cm-Sd-micro-Card-Extender-Cable/dp/B007WYRO7O
>
>
> Even jumper cables are suitable at 350 Mhz..
>
> The specification for the SD protocol is nearly completely available
> in the Simple SD Specification freely available on sdcard.org - the
> state machines I'd need are bootup (3.3v), negotiating to high speed
> (which switches to 1.8v) and data transfer.
>
> The SD-MUX option wears out, I've run through a couple SD cards
> already which is why I'm looking into the FPGA approach - not to
> mention faster in speed.
>
> I'm uncertain about FPGA sizing and FPGA's in general which is why I
> posted here - there doesn't seem to be any relatable data between
> different FPGA manufacturers and I'm trying to keep costs low if I
> need to make a lot of boards.

People say the specs are available, but I looked for the mechanical 
details and never found them.

My understanding is you can use an SD card in SPI mode (one bit data 
width) but the 4 bit mode is not specified.  Maybe that has changed and 
my info is out of date.

I saw the cables when looking for a mail SD card connector.  I don't 
know how well they work.  I didn't know SD cards ran at 350 MHz, but at 
that speed you need to pay careful attention to the details of 
connections.  Signal integrity (SI) can be a significant issue.

Even a small FPGA will do the job of providing the SD card interface. 
The USB interface requires a lot of code (relatively speaking) but is 
well supported by vendors and various other sources with example code 
for MCUs.

Lattice has a number of low end FPGAs that use internal flash to load 
the config RAM so an external chip is not needed.  That is why Antti 
used an XP device.  They are now obsolete, but Lattice has the XP2, XO2 
and XO3 lines in addition to the iCE40 family.  The iCE40 line uses one 
time programmable NVM to load the RAM though.  If you want the chip to 
be reconfigurable in the field you need an external flash chip.

-- 

Rick C

Article: 159527
Subject: Re: Phrasing!
From: rickman <gnuarm@gmail.com>
Date: Fri, 2 Dec 2016 06:58:44 -0500
Links: << >>  << T >>  << A >>
On 12/2/2016 3:10 AM, o pere o wrote:
> On 26/11/16 05:57, rickman wrote:
>> On 11/25/2016 4:26 PM, Tim Wescott wrote:
>>>
>>> Reading this whole thread, I'm reminded of a gripe I have about the FPGA
>>> manufacturers, or at least Xilinx and Altera.
>>>
>>> If they -- or just any one of them -- would PUBLISH the details of how
>>> their bitfiles map to the workings of their FPGAs, then all of a sudden
>>> that company's stuff would be the subject of all the intensive
>>> university
>>> research on FPGA optimization that you might desire, and possibly even
>>> see an open-source tools ecology grow around its parts.
>>>
>>> It wouldn't immediately lead to nirvana, but it may at least lead to
>>> more
>>> and better optimization, and lots of people experimenting with different
>>> optimization approaches.
>>
>> Let's say I am Xilinx...  I have a bazillion dollars of investment into
>> my products and the support software.  I sell to large companies who
>> want reliable, consistent products.  I open up my chip design and a
>> bunch of university idealists start creating tools for my devices.  The
>> tools work to varying degrees and are used for a number of different
>> designs by a wide variety of groups.
>>
>> So what happens when some of these groups report problems "with the
>> chips"?  Are these problems really with the chips or with the tools?  If
>> any of these groups ask us to deal with these problems, how do we begin?
>>
>> In other words, how do we keep these tools from causing problems with
>> our reputation?
>>
>
> This is a point, although a weak one. The same should also happen to the
> microcontroller industry... but does not. They are quite happy selling
> chips that are being programmed by the open-sourced gcc toolchain.

I think this is apples and oranges.  It is easy to look at the output of 
a compiler and see what it is doing.  The details of the configuration 
file for an FPGA is not so easy to analyze.  Also, the configuration bit 
stream isn't just a matter of telling the chip what to do, it can set up 
internal conflicts that can damage the chip.

Even if the FPGA vendors release their technical info on the 
configuration bit stream, it is a very complex thing to deal with.

-- 

Rick C

Article: 159528
Subject: Re: SD card emulation
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 02 Dec 2016 12:31:34 +0000 (GMT)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> I saw the cables when looking for a mail SD card connector.  I don't 
> know how well they work.  I didn't know SD cards ran at 350 MHz, but at 
> that speed you need to pay careful attention to the details of 
> connections.  Signal integrity (SI) can be a significant issue.

UHS-I goes up to 104MHz (104MB/s SDR), and then UHS-II adds a differential
interface (up to 312MB/s at present).

> Even a small FPGA will do the job of providing the SD card interface. 
> The USB interface requires a lot of code (relatively speaking) but is 
> well supported by vendors and various other sources with example code 
> for MCUs.

A small FPGA will handle the physical interface, but implementing the card
end of the protocol is more complex (though not as bad as USB).  I'd suggest
you want to use an FPGA to interface to a CPU (or a soft CPU inside a larger
FPGA) and running software to implement the protocol - doing it all in
hardware will be pretty painful.

Another option might be to take an existing SD card chip and use an FPGA to
emulate the NAND flash it's expecting to talk to.  The NAND protocol is a
lot cleaner than SD.  However you'd have to force the SD chip to disabling
wear levelling somehow, otherwise it would shuffle your blocks around.

It sounds like a somewhat finnicky project, particularly if you're expecting
to get decent speed out of it...

Theo

Article: 159529
Subject: Re: Phrasing!
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 02 Dec 2016 16:08:06 +0000 (GMT)
Links: << >>  << T >>  << A >>
o pere o <me@somewhere.net> wrote:
> This is a point, although a weak one. The same should also happen to the 
> microcontroller industry... but does not. They are quite happy selling 
> chips that are being programmed by the open-sourced gcc toolchain.

An ISA is an API.   A lot of work goes on implementing the microarchitecture
which implements the API, either in hardware or software (microcode). 
Another lot of work goes on proving that the implementation matches the API
and is bug-free (and 'halt and catch fire' is definitely a bug).

FPGA silicon doesn't have an API, you just have the raw transistors to
control.  The main safeguards to prevent them generating flame-inducing
configurations (or more prosaically customer returns) are in the tools.

You can put an API on top of an FPGA (eg as the 'FPGA virtualisation' folks
do) but the performance and flexibility impact is substantial.  As far as
I'm aware of the current state of FPGA virtualisation (admittedly not that
much), there's nothing there that would be usable in a product anytime soon.

Theo

Article: 159530
Subject: Re: Phrasing!
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 2 Dec 2016 12:41:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, November 25, 2016 at 4:26:11 PM UTC-5, Tim Wescott wrote:
>=20
> If they -- or just any one of them -- would PUBLISH the details of how=20
> their bitfiles map to the workings of their FPGAs, then all of a sudden=
=20
> that company's stuff would be the subject of all the intensive university=
=20
> research on FPGA optimization that you might desire, and possibly even=20
> see an open-source tools ecology grow around its parts.
>=20

I kind of doubt that would happen.  I don't think there are enough hardware=
 knowledgeable folks who can write good software.  If there were, we would =
all be simulating with some open source VHDL+Verilog simulator that puts Mo=
delsim and Aldec to shame [1].  But instead most people I think are using M=
odelsim/Aldec or some lame simulator that comes bundled with the tools.

Since there apparently aren't many folks diving in to develop something tha=
t would benefit many with a decent simulator, why would you think there wou=
ld be enough to dive in and help develop something that benefits a subset o=
f that market?

Open source developers tend to use their tools in their day to day work as =
well.  Those developers 'only' need to be good at developing software in or=
der to develop open source stuff.  When you talk about open source tools to=
 be used for hardware development, you would want to have someone good at d=
eveloping hardware and software so that the tools they develop they would t=
hen use day to day.  If nothing else, there are fewer of those folks that h=
ave both skills and, based on the lack of developers for open source simula=
tors, I think there just isn't the critical mass.

Manufacturers keeping their details secret could be seen as nothing more th=
an their seeing that there aren't enough people out there who could even de=
velop what is needed in an open source scenario.  So they pay people to dev=
elop what they need.

> It wouldn't immediately lead to nirvana, but it may at least lead to more=
=20
> and better optimization, and lots of people experimenting with different=
=20
> optimization approaches.
>=20
I know you're not holding your breath waiting for that nirvana...but I'd wa=
ger that you will have taken your last breath long before such nirvana was =
reached.

Kevin Jennings

[1] Yes I know about GHDL and it is and appears to have always been a one m=
an band.  The original band member left the band and years later someone el=
se picked it up.  Last two releases are 0.31 released in Oct-2015 and 0.33 =
in Dec-2015, nothing new in about 12 months and counting.  It is still not =
up to release 1.0 and there will be another revision to the VHDL standard i=
n 2017.  One person can only do so much...in addition to doing something th=
at puts food on the table.

Article: 159531
Subject: Re: Phrasing!
From: Brian Davis <brimdavis@aol.com>
Date: Fri, 2 Dec 2016 16:28:36 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, December 2, 2016 at 3:41:04 PM UTC-5, KJ wrote:
>
> [1] Yes I know about GHDL <snip>
> Last two releases are 0.31 released in Oct-2015 and 0.33 in Dec-2015,
> nothing new in about 12 months and counting.
>
Tristan moved the development to GitHub:
  https://github.com/tgingold/ghdl/releases

-Brian

Article: 159532
Subject: Re: Phrasing!
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 2 Dec 2016 16:52:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, December 2, 2016 at 7:28:42 PM UTC-5, Brian Davis wrote:
> On Friday, December 2, 2016 at 3:41:04 PM UTC-5, KJ wrote:
> >
> > [1] Yes I know about GHDL <snip>
> > Last two releases are 0.31 released in Oct-2015 and 0.33 in Dec-2015,
> > nothing new in about 12 months and counting.
> >
> Tristan moved the development to GitHub:
>   https://github.com/tgingold/ghdl/releases

That's good to hear, now you need to let Google in on the secret.  I do see=
 there is mention of the move to Github on the summary page on SourceForge =
page, but maybe you should consider pulling all the old stuff down from Sou=
rceForge and put some more redirection links to the new home.

Kevin Jennings

Article: 159533
Subject: Re: Phrasing!
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 2 Dec 2016 18:32:44 -0800 (PST)
Links: << >>  << T >>  << A >>
> I kind of doubt that would happen.  I don't think there are enough hardwa=
re knowledgeable folks who can write good software.  If there were, we woul=
d all be simulating with some open source VHDL+Verilog simulator that puts =
Modelsim and Aldec to shame [1].  But instead most people I think are using=
 Modelsim/Aldec or some lame simulator that comes bundled with the tools.

I agree.  It doesn't seem likely that there would be a lot of people versed=
 in low-level silicon design and high-level software and who would also be =
willing to put in a lot of time for free.

I don't suppose there is anything stopping somebody from making a synthesiz=
er--you can just convert RTL into structural HDL containing primitives--but=
 I don't see a lot of free synthesizers around. 

Article: 159534
Subject: Libre tools, was Re: Phrasing!
From: Jan Coombs <jenfhaomndgfwutc@murmic.plus.com>
Date: Sat, 3 Dec 2016 13:44:48 +0000
Links: << >>  << T >>  << A >>
On Fri, 2 Dec 2016 03:32:16 -0800 (PST)
KJ <kkjennings@sbcglobal.net> wrote:

> Also consider that on the gcc side of things that they have a
> lot of people who know how to write software that are writing
> and developing the gcc software.  There aren't nearly as many
> people who know how to write software working on software
> stuff for hardware like FPGAs.  Witness that we don't have
> much of anything other than GHDL as a basic simulator.
> Development on that is up to the whims of one person who
> chooses to work on it (or not in which case everything
> stops...as it has of late).

The MyHDL community is vibrant [1], and this fast[2] simulator
exports Verilog and VHDL for synthesis.
 

> It wouldn't surprise me if FPGA companies probably consider
> that the open source community would take forever to develop
> anything.

I'm using open source tools [3]. As for community, there are many
users, not sure about developers, maybe clues here [4].

Clifford did/does warn about frying chips, but the value of the
project far exceeds the cost of a few sacrificial ICs.  

Jan Coombs
-- 
[1] http://myhdl.org/
[2] http://myhdl.org/docs/performance.html
[3] http://www.clifford.at/icestorm/
[4] https://www.reddit.com/r/yosys/comments/4ocilz/icestorm_adding_support_for_new_devices_part_1/


Article: 159535
Subject: Re: Help finding Xilinx software for HW-130 programmer
From: Joe Z <f6ceedb9c75b52f7fcc0a55cf0cfbf5d_1051@example.com>
Date: Mon, 05 Dec 2016 21:37:02 -0600
Links: << >>  << T >>  << A >>
responding to
http://www.electrondepot.com/fpga/help-finding-xilinx-software-for-hw-130-programmer-81804-.htm
, Joe Z wrote:
> gnuarm  wrote:
>
> On 5/3/2016 2:23 PM, Tim Regeant wrote: 
> > I am searching for some Xilinx programmer software for the HW-130
> unit 
> > from around 1996-2000. 
> > 
> > Looking the the DOS version.  The filename was HW130.ZIP 
> > 
> > Also looking for the 16-bit windows version HW130W.ZIP. 
> > 
> > Thank you for any help you can offer! 
> 
> I have software from that era along with a license key.  I could get it 
> 
> to you. 
> 
> --  
> 
> Rick C 
> 

Hi Rick,

I'm in the same boat - I have an old XC17S that I need to read and re-create. 
I'm planning to grab an HW-130 on ebay, but the software for it is nowhere to
be had... Can you email it to me too?

-Joe Z




Article: 159536
Subject: Re: Help finding Xilinx software for HW-130 programmer
From: rickman <gnuarm@gmail.com>
Date: Tue, 6 Dec 2016 00:44:26 -0500
Links: << >>  << T >>  << A >>
On 12/5/2016 10:37 PM, Joe Z wrote:
> responding to
> http://www.electrondepot.com/fpga/help-finding-xilinx-software-for-hw-130-programmer-81804-.htm
>
> , Joe Z wrote:
>> gnuarm  wrote:
>>
>> On 5/3/2016 2:23 PM, Tim Regeant wrote: > I am searching for some
>> Xilinx programmer software for the HW-130
>> unit > from around 1996-2000. > > Looking the the DOS version.  The
>> filename was HW130.ZIP > > Also looking for the 16-bit windows version
>> HW130W.ZIP. > > Thank you for any help you can offer!
>> I have software from that era along with a license key.  I could get it
>> to you.
>> --
>> Rick C
>
> Hi Rick,
>
> I'm in the same boat - I have an old XC17S that I need to read and
> re-create. I'm planning to grab an HW-130 on ebay, but the software for
> it is nowhere to
> be had... Can you email it to me too?

It was on a number of disks along with several dongles.   I already sent 
it to whoever it was that wanted it.  It took me forever to find it.  My 
office is a total mess these days as I haven't really worked there for 
some time and it has become the warehouse from Indiana Jones.  But it 
did finally turn up and I put it in the mail.

-- 

Rick C

Article: 159537
Subject: Linux OS for FPGA worth
From: Cecil Bayona <cbayona@cbayona.com>
Date: Mon, 5 Dec 2016 23:59:08 -0600
Links: << >>  << T >>  << A >>
I keep debating if I should start switching my PCs from Windows 10 to 
Linux, several of my main PCs are on Win 10 Preview, and Microsoft made 
it so you can't get off until the next non-preview release.

I play around with Lattice, and Xilinx FPGAs, I know Lattice has their 
Diamond software available for Linux, and Xilinx has Vivado and it's 
older software also available for Linux also, but I've read that it's 
difficult to get them to work with Linux.

I use Mint Linux X64 a derivative of Ubuntu, so anyone out there has 
used with with either of that software and how difficult was it to get 
it working?

Thanks
-- 
Cecil - k5nwa

Article: 159538
Subject: Re: Linux OS for FPGA worth
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Tue, 6 Dec 2016 08:56:00 +0000
Links: << >>  << T >>  << A >>
On 06/12/16 05:59, Cecil Bayona wrote:
> I keep debating if I should start switching my PCs from Windows 10 to Linux,
> several of my main PCs are on Win 10 Preview, and Microsoft made it so you can't
> get off until the next non-preview release.
>
> I play around with Lattice, and Xilinx FPGAs, I know Lattice has their Diamond
> software available for Linux, and Xilinx has Vivado and it's older software also
> available for Linux also, but I've read that it's difficult to get them to work
> with Linux.
>
> I use Mint Linux X64 a derivative of Ubuntu, so anyone out there has used with
> with either of that software and how difficult was it to get it working?

Vivado on Xubuntu was trivial to install and get working.
Personally I would expect it to be more difficult to get
it working on Windows, but the manufacturer should have
sorted that out.

If in doubt, download it and install it in a virtual machine
image. There's even an argument that should be done for the
work environment, particularly if you might need to revisit
a design later.


Article: 159539
Subject: Re: Linux OS for FPGA worth
From: Cecil Bayona <cbayona@cbayona.com>
Date: Tue, 6 Dec 2016 03:27:20 -0600
Links: << >>  << T >>  << A >>
On 12/6/2016 2:56 AM, Tom Gardner wrote:
> On 06/12/16 05:59, Cecil Bayona wrote:
>> I keep debating if I should start switching my PCs from Windows 10 to
>> Linux,
>> several of my main PCs are on Win 10 Preview, and Microsoft made it so
>> you can't
>> get off until the next non-preview release.
>>
>> I play around with Lattice, and Xilinx FPGAs, I know Lattice has their
>> Diamond
>> software available for Linux, and Xilinx has Vivado and it's older
>> software also
>> available for Linux also, but I've read that it's difficult to get
>> them to work
>> with Linux.
>>
>> I use Mint Linux X64 a derivative of Ubuntu, so anyone out there has
>> used with
>> with either of that software and how difficult was it to get it working?
>
> Vivado on Xubuntu was trivial to install and get working.
> Personally I would expect it to be more difficult to get
> it working on Windows, but the manufacturer should have
> sorted that out.
>
> If in doubt, download it and install it in a virtual machine
> image. There's even an argument that should be done for the
> work environment, particularly if you might need to revisit
> a design later.
>

Are you speaking of using a virtual PC for the development?

Under Windows 10 I also setup two Virtual CPUs running Win 7 i386 and 
X64 because some of the software development tools would not work with 
Windows 10 and some had issues with X64. I was a little slower but not 
by much mostly because the Diamond software had less RAM under the 32 
bit Virtual PC but it was good enough. An advantage was I could copy the 
VM to any other PC I desired with little effort, and it was easy to keep 
a backup of the entire system. I used vmWare and had little difficulty 
having the VM talk to the FPGA board.

Right now I mostly use the Win 7 X64 VM most of the time with few issues 
rather than use Windows 10 where I have more problems than Windows 7. I 
supposed it might be better if I took one of my Window 10 CPUs, image 
it, then restore Window 7 and run that natively but I like to give Linux 
a shot at it since my machines that have Mint Linux just work and rarely 
have any problems like Windows does.

-- 
Cecil - k5nwa

Article: 159540
Subject: Re: Linux OS for FPGA worth
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Tue, 6 Dec 2016 09:42:32 +0000
Links: << >>  << T >>  << A >>
On 06/12/16 09:27, Cecil Bayona wrote:
> On 12/6/2016 2:56 AM, Tom Gardner wrote:
>> On 06/12/16 05:59, Cecil Bayona wrote:
>>> I keep debating if I should start switching my PCs from Windows 10 to
>>> Linux,
>>> several of my main PCs are on Win 10 Preview, and Microsoft made it so
>>> you can't
>>> get off until the next non-preview release.
>>>
>>> I play around with Lattice, and Xilinx FPGAs, I know Lattice has their
>>> Diamond
>>> software available for Linux, and Xilinx has Vivado and it's older
>>> software also
>>> available for Linux also, but I've read that it's difficult to get
>>> them to work
>>> with Linux.
>>>
>>> I use Mint Linux X64 a derivative of Ubuntu, so anyone out there has
>>> used with
>>> with either of that software and how difficult was it to get it working?
>>
>> Vivado on Xubuntu was trivial to install and get working.
>> Personally I would expect it to be more difficult to get
>> it working on Windows, but the manufacturer should have
>> sorted that out.
>>
>> If in doubt, download it and install it in a virtual machine
>> image. There's even an argument that should be done for the
>> work environment, particularly if you might need to revisit
>> a design later.
>>
>
> Are you speaking of using a virtual PC for the development?

That's the argument. There are pros and cons, of course.


> Under Windows 10 I also setup two Virtual CPUs running Win 7 i386 and X64
> because some of the software development tools would not work with Windows 10
> and some had issues with X64. I was a little slower but not by much mostly
> because the Diamond software had less RAM under the 32 bit Virtual PC but it was
> good enough. An advantage was I could copy the VM to any other PC I desired with
> little effort, and it was easy to keep a backup of the entire system. I used
> vmWare and had little difficulty having the VM talk to the FPGA board.

Why am I not surprised! That illustrates a pro of the VM approach.


> Right now I mostly use the Win 7 X64 VM most of the time with few issues rather
> than use Windows 10 where I have more problems than Windows 7. I supposed it
> might be better if I took one of my Window 10 CPUs, image it, then restore
> Window 7 and run that natively but I like to give Linux a shot at it since my
> machines that have Mint Linux just work and rarely have any problems like
> Windows does.

On the rare occasions when I need Windows, I run XP in a VM.
I have both fully patched and from-the-CD images, and clone
them when experimenting.

I have no plans to buy Win10; I don't think I'm clever enough
to keep it secure.


Article: 159541
Subject: Re: Help finding Xilinx software for HW-130 programmer
From: Tim Regeant <TimRegeant@gmail.com>
Date: Tue, 6 Dec 2016 13:47:48 -0500
Links: << >>  << T >>  << A >>
On 12/5/2016 10:37 PM, Joe Z wrote:
> responding to
> http://www.electrondepot.com/fpga/help-finding-xilinx-software-for-hw-130-programmer-81804-.htm
>
> , Joe Z wrote:
>> gnuarm  wrote:
>>
>> On 5/3/2016 2:23 PM, Tim Regeant wrote: > I am searching for some
>> Xilinx programmer software for the HW-130
>> unit > from around 1996-2000. > > Looking the the DOS version.  The
>> filename was HW130.ZIP > > Also looking for the 16-bit windows version
>> HW130W.ZIP. > > Thank you for any help you can offer!
>> I have software from that era along with a license key.  I could get it
>> to you.
>> --
>> Rick C
>
> Hi Rick,
>
> I'm in the same boat - I have an old XC17S that I need to read and
> re-create. I'm planning to grab an HW-130 on ebay, but the software for
> it is nowhere to
> be had... Can you email it to me too?
>
> -Joe Z
>
>
>


Send me an email with what you need.  I have the software.

Article: 159542
Subject: Re: The TimingAnalyzer (Timing Diagrams and Analysis)
From: dfab1954@gmail.com
Date: Wed, 7 Dec 2016 10:17:09 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Svenn,

I recently released a new version of the TimingAnalyzer that includes the p=
ython function you requested.  I'm also working on creating cycle accurate =
VHDL testbenches that read test vectors created from timing diagrams that r=
epresent transactions.  This might be something else you would be intereste=
d in since you working with VHDL. =20

If anyone is interested in following the work being done or contributing to=
 new feature ideas, join the google group.


Regards,
Dan

www.timing-diagrams.com
http://groups.google.com/group/timinganalyzer


=20


Article: 159543
Subject: Custom timing on Altera Cyclone V GX dev board
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 7 Dec 2016 10:49:52 -0800 (PST)
Links: << >>  << T >>  << A >>
I have a "Cyclone V GX Starter Board," with an Altera Cyclone V GX
5CGXFC5CF27C7N.

I've designed a logic layout for a video card that only does SVGA
output in graphics modes, and particularly only 1024 x 768 x 75 Hz
refresh rate right now.

I've developed a custom protocol for using single bytes per pixel,
and a palette of 256 colors from a possible range of 4,096 colors.

-----
I've gotten everything designed and I'd like to put it to hardware
now.  I honestly don't know where to begin on this Altera.

I'd like to double-clock the pixel clock so I can conduct operations
in-between use.  It requires about a 79 MHz clock at 1024x768x75,
so I'd need about a 168 MHz clock.

Can somebody point me in the right direction, please?

Best regards,
Rick C. Hodgin

Article: 159544
Subject: Re: Custom timing on Altera Cyclone V GX dev board
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 07 Dec 2016 19:09:33 +0000 (GMT)
Links: << >>  << T >>  << A >>
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> I've gotten everything designed and I'd like to put it to hardware
> now.  I honestly don't know where to begin on this Altera.
> 
> I'd like to double-clock the pixel clock so I can conduct operations
> in-between use.  It requires about a 79 MHz clock at 1024x768x75,
> so I'd need about a 168 MHz clock.
> 
> Can somebody point me in the right direction, please?

You need a PLL.  You can either:

Go to IP Catalog in Quartus and instantiate one.  This has a wizard that
asks you all the questions and generates some Verilog that does it.  It's
then up to you to wire it up.

or

If you use Qsys (a good idea) you can just drop in a PLL component and fill
in the answers to the questions.  You can then connect up the ports with the
clicky interface - which will also keep track of your clock domains and
insert clock crossing buffers where needed.

Theo

Article: 159545
Subject: Re: Custom timing on Altera Cyclone V GX dev board
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 7 Dec 2016 11:22:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, December 7, 2016 at 2:09:37 PM UTC-5, Theo Markettos wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > I've gotten everything designed and I'd like to put it to hardware
> > now.  I honestly don't know where to begin on this Altera.
> > 
> > I'd like to double-clock the pixel clock so I can conduct operations
> > in-between use.  It requires about a 79 MHz clock at 1024x768x75,
> > so I'd need about a 168 MHz clock.
> > 
> > Can somebody point me in the right direction, please?
> 
> You need a PLL.  You can either:
> 
> Go to IP Catalog in Quartus and instantiate one.  This has a wizard that
> asks you all the questions and generates some Verilog that does it.  It's
> then up to you to wire it up.
> 
> or
> 
> If you use Qsys (a good idea) you can just drop in a PLL component and fill
> in the answers to the questions.  You can then connect up the ports with the
> clicky interface - which will also keep track of your clock domains and
> insert clock crossing buffers where needed.
> 
> Theo

Will I be able to create a 158 MHz clock on this device?  Or is that
beyond its abilities?  Also, I have add and compare circuits that need
to run at about 79 MHz.  Will those work properly?

I'm moving from the area of digital theory design to FPGA programming
reality.  I'm not sure what to expect.

Best regards,
Rick C. Hodgin

Article: 159546
Subject: Re: Custom timing on Altera Cyclone V GX dev board
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 07 Dec 2016 20:07:14 +0000 (GMT)
Links: << >>  << T >>  << A >>
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> Will I be able to create a 158 MHz clock on this device?  Or is that
> beyond its abilities?  Also, I have add and compare circuits that need
> to run at about 79 MHz.  Will those work properly?

The /device/ should be capable of up to 300-400MHz - at least that's what
I've seem in general use.  However it's your problem to make a design that
will run at the speed you use to run it at.  I wouldn't have thought you
would have big problems at 79MHz, and might be OK at 158MHz - it really
depends.

TimeQuest timing analyser will tell you, among other things, the maximum
clock speed that each clock domain will run at.  Assuming you have
constrained your input clocks appropriately (ie have an SDC file that
indicates their speeds, and any relations between them) then Timequest will
warn if your design fails to meet your timing constraints.  If you have a
PLL, it knows the input clock and will calculate the speeds of the generated
clocks, so in general you just need to tell it the input speeds and it'll
figure out the rest.

> I'm moving from the area of digital theory design to FPGA programming
> reality.  I'm not sure what to expect.

You might find it useful to have a read through an intro to the tools - for
instance this my brief rundown aimed at second year university students (in
the middle of a course doing other things including verilog and
bare-metal software development):

http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html

Theo

Article: 159547
Subject: Re: Custom timing on Altera Cyclone V GX dev board
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Wed, 7 Dec 2016 12:45:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, December 7, 2016 at 3:07:21 PM UTC-5, Theo Markettos wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > Will I be able to create a 158 MHz clock on this device?  Or is that
> > beyond its abilities?  Also, I have add and compare circuits that need
> > to run at about 79 MHz.  Will those work properly?
> 
> The /device/ should be capable of up to 300-400MHz - at least that's what
> I've seem in general use.  However it's your problem to make a design that
> will run at the speed you use to run it at.  I wouldn't have thought you
> would have big problems at 79MHz, and might be OK at 158MHz - it really
> depends.
> 
> TimeQuest timing analyser will tell you, among other things, the maximum
> clock speed that each clock domain will run at.  Assuming you have
> constrained your input clocks appropriately (ie have an SDC file that
> indicates their speeds, and any relations between them) then Timequest will
> warn if your design fails to meet your timing constraints.  If you have a
> PLL, it knows the input clock and will calculate the speeds of the generated
> clocks, so in general you just need to tell it the input speeds and it'll
> figure out the rest.
> 
> > I'm moving from the area of digital theory design to FPGA programming
> > reality.  I'm not sure what to expect.
> 
> You might find it useful to have a read through an intro to the tools - for
> instance this my brief rundown aimed at second year university students (in
> the middle of a course doing other things including verilog and
> bare-metal software development):
> 
> http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html
> 
> Theo

Excellent info.  Thank you, Theo.

I'm meeting with a local hardware project Meetup group this weekend,
so hopefully I'll pick up a few pointers.  They typically go over a
design and build from beginning to end that one of the members from
the group has already had success in getting it to work.

Best regards,
Rick C. Hodgin

Article: 159548
Subject: Re: Custom timing on Altera Cyclone V GX dev board
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Thu, 8 Dec 2016 12:12:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Wednesday, December 7, 2016 at 3:45:10 PM UTC-5, Rick C. Hodgin wrote:
> On Wednesday, December 7, 2016 at 3:07:21 PM UTC-5, Theo Markettos wrote:
> > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > > Will I be able to create a 158 MHz clock on this device?  Or is that
> > > beyond its abilities?  Also, I have add and compare circuits that need
> > > to run at about 79 MHz.  Will those work properly?
> > 
> > The /device/ should be capable of up to 300-400MHz - at least that's what
> > I've seem in general use.  However it's your problem to make a design that
> > will run at the speed you use to run it at.  I wouldn't have thought you
> > would have big problems at 79MHz, and might be OK at 158MHz - it really
> > depends.
> > 
> > TimeQuest timing analyser will tell you, among other things, the maximum
> > clock speed that each clock domain will run at.  Assuming you have
> > constrained your input clocks appropriately (ie have an SDC file that
> > indicates their speeds, and any relations between them) then Timequest will
> > warn if your design fails to meet your timing constraints.  If you have a
> > PLL, it knows the input clock and will calculate the speeds of the generated
> > clocks, so in general you just need to tell it the input speeds and it'll
> > figure out the rest.
> > 
> > > I'm moving from the area of digital theory design to FPGA programming
> > > reality.  I'm not sure what to expect.
> > 
> > You might find it useful to have a read through an intro to the tools - for
> > instance this my brief rundown aimed at second year university students (in
> > the middle of a course doing other things including verilog and
> > bare-metal software development):
> > 
> > http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html
> > 
> > Theo
> 
> Excellent info.  Thank you, Theo.
> 
> I'm meeting with a local hardware project Meetup group this weekend,
> so hopefully I'll pick up a few pointers.  They typically go over a
> design and build from beginning to end that one of the members from
> the group has already had success in getting it to work.

I'm going to start by trying to get the address generation circuit and
read memory working.  I have designed a staging register, and a use
register, so the next 8-byte read can come in the background while the
pixel clock is shifting between 8-bit blocks in the use register.

I think this will provide adequate timing for video modes even well
beyond 1024 x 768 x 75 Hz.

Best regards,
Rick C. Hodgin

Article: 159549
Subject: Re: Custom timing on Altera Cyclone V GX dev board
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sat, 10 Dec 2016 17:47:08 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, December 8, 2016 at 3:12:44 PM UTC-5, Rick C. Hodgin wrote:
> On Wednesday, December 7, 2016 at 3:45:10 PM UTC-5, Rick C. Hodgin wrote:
> > On Wednesday, December 7, 2016 at 3:07:21 PM UTC-5, Theo Markettos wrote:
> > > Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > > > Will I be able to create a 158 MHz clock on this device?  Or is that
> > > > beyond its abilities?  Also, I have add and compare circuits that need
> > > > to run at about 79 MHz.  Will those work properly?
> > > 
> > > The /device/ should be capable of up to 300-400MHz - at least that's what
> > > I've seem in general use.  However it's your problem to make a design that
> > > will run at the speed you use to run it at.  I wouldn't have thought you
> > > would have big problems at 79MHz, and might be OK at 158MHz - it really
> > > depends.
> > > 
> > > TimeQuest timing analyser will tell you, among other things, the maximum
> > > clock speed that each clock domain will run at.  Assuming you have
> > > constrained your input clocks appropriately (ie have an SDC file that
> > > indicates their speeds, and any relations between them) then Timequest will
> > > warn if your design fails to meet your timing constraints.  If you have a
> > > PLL, it knows the input clock and will calculate the speeds of the generated
> > > clocks, so in general you just need to tell it the input speeds and it'll
> > > figure out the rest.
> > > 
> > > > I'm moving from the area of digital theory design to FPGA programming
> > > > reality.  I'm not sure what to expect.
> > > 
> > > You might find it useful to have a read through an intro to the tools - for
> > > instance this my brief rundown aimed at second year university students (in
> > > the middle of a course doing other things including verilog and
> > > bare-metal software development):
> > > 
> > > http://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/fpga-intro.html
> > > 
> > > Theo
> > 
> > Excellent info.  Thank you, Theo.
> > 
> > I'm meeting with a local hardware project Meetup group this weekend,
> > so hopefully I'll pick up a few pointers.  They typically go over a
> > design and build from beginning to end that one of the members from
> > the group has already had success in getting it to work.
> 
> I'm going to start by trying to get the address generation circuit and
> read memory working.  I have designed a staging register, and a use
> register, so the next 8-byte read can come in the background while the
> pixel clock is shifting between 8-bit blocks in the use register.
> 
> I think this will provide adequate timing for video modes even well
> beyond 1024 x 768 x 75 Hz.

I began working with Altera's Quartus II software last night and had
difficulty in understanding how it works.  In addition, as I began to
write verilog code to reproduce my design, it loses so much in the
translation into text.

I've decided to complete my Logician tool so I can do a graphical
design and then have it generate gate, wire, and net verilog source
code for compilation in the tool.

I'm an image/design-thinker ... not a convert-to-text-thinker. :-)

Best regards,
Rick C. Hodgin



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
2017JanFebMarApr2017

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