Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 159025

Article: 159025
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: rickman <gnuarm@gmail.com>
Date: Thu, 16 Jun 2016 17:13:26 -0400
Links: << >>  << T >>  << A >>
On 6/16/2016 1:57 PM, Jecel wrote:
> On Wednesday, June 15, 2016 at 7:14:06 PM UTC-3, Rickman wrote:
>> On 6/15/2016 5:43 PM, Jecel wrote:
>>> "the same command line" might be the key to our differences. In the
>>> native C64 Basic command line I can type something like
>>>
>>> PRINT (MADD/4)+1
>>>
>>> and see the result. In a cross compiling Basic I can't do that.
>>
>> There's the problem.  I'm using Forth.  I didn't know we were talking
>> about BASIC.
>
> :-)
>
> So we type
>
> MADD @ 4 / 1 + .
>
> instead. The point is that I don't have to first put that expression
> in a colon definition, compile it, and then send it to the target
> board to see the result.
>
>>> The J1 can't address much memory, so a native Forth is possible but would
>>> be a tight fit.
>>
>> I don't recall the limitation, but I would expect it to be on the order
>> of many KB.
>
> Let me check:
>
> http://excamera.com/files/j1.pdf
>
> "All target addresses - for call, jump and conditional branch
> - are 13-bit. This limits code size to 8K words, or 16K bytes."
>
> Data uses 15 bit byte addresses, but the top half of the memory
> map is reserved for I/O. So was have 16KB in all to play with.
>
>> Mecrisp is not so large and in fact, I'm pretty sure it has
>> been ported to the J1.  I seem to recall this was done using an open
>> source package (the only one I've ever heard of) that compiles to a bit
>> stream.  In a fit of enthusiasm I believe Matthias Koch ported his Forth
>> to this target making the entire effort open source.  I can't recall for
>> sure, but I'm pretty sure the hardware is also open source.
>
> Ok, so the answer to the original question is "yes"? Good. I've had some
> nice machines (Mac, Sun Utra 5+, XO-1 from One Laptop Per Child) with
> OpenFirmware (OpenBoot, as Sun called it) and it is a nice token threaded
> Forth that can be used interactively. Not only is token threading
> really compact, but it can also be used on Harvard architecture chips
> like the Atmel AVR8.
>
>>> You mentioned a lack of mass storage on the target device, but these days
>>> you can easily have 64Kb of Flash or more.
>>
>> 64 kB of on target flash is not of much value for storing source.  You
>> have virtually no tools for printing, copying, backup, etc.  I use a PC
>> for all that.
>
> Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
> it might be enough. Most early microcomputers had 80KB floppy disks.

I have no idea what you are trying to say with this.  Lots of things 
were done in the early days of programming including using toggle 
switches to enter programs.  I don't wish to duplicate any of that.


>>> In any case, my own SiliconSqueak is way larger than the J1 and is meant
>>> for boards with more resources, though not necessarily as large as a
>>> Raspberry Pi.
>>
>> You mean an FPGA board?  The rPi has a higher end ARM processor.
>
> The R-Pi also has SDRAM, HDMI output, USBs and Ethernet which is also
> the case for some FPGA boards. And those with chips like Zynq have
> FPGAs and ARMs.
>
> What I was saying was that I am also interested in FPGA boards with not
> as much memory and with poorer I/O (VGA and PS/2, for example) than
> the Pi.

I don't know what you are trying to say here.  You mentioned your 
"SiliconSqueak" which I assume is a processor design.  You seem to be 
talking about running it on an rPi which doesn't make sense.  Were you 
just using the rPi as a point of comparison?

-- 

Rick C

Article: 159026
Subject: Active HDL Generic Controls
From: rickman <gnuarm@gmail.com>
Date: Thu, 16 Jun 2016 17:35:13 -0400
Links: << >>  << T >>  << A >>
I am working with Active HDL and I'm pretty sure in the past I was able 
to set generics at the top level from within the simulator.  I see in 
the Design, Settings dialog box they have a Simulation, 
Generic/Parameters choice which looks like it should display design 
generics, but I can't see them.  The help file talks about editing these 
items, but I see no editing controls either.

Anyone know what I'm doing wrong?

-- 

Rick C

Article: 159027
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: GaborSzakacs <gabor@alacron.com>
Date: Thu, 16 Jun 2016 17:39:40 -0400
Links: << >>  << T >>  << A >>
Jecel wrote:

[snip]

> 
> What I was saying was that I am also interested in FPGA boards with not
> as much memory and with poorer I/O (VGA and PS/2, for example) than
> the Pi.
> 
> -- Jecel

Many low-end FPGA boards are out there, but in general the peripherals
are richer on the boards with a larger FPGA.  For a bare-bones starter
board with VGA and USB and PMOD, you could look at:

https://www.nandland.com/goboard/introduction.html

However the ICE40 on that board is not very large for playing with
embedded processors.

If you can live with HDMI instead of VGA, then possibly the Scarab
MiniSpartan6+ would be a possibility.  Just be aware that the
SDRAM on that board is single-data-rate and won't work with the
built-in hard memory control block of the Spartan-6.

https://www.scarabhardware.com/minispartan6/

-- 
Gabor

Article: 159028
Subject: Lattice Diamond and VHDL-2008
From: rickman <gnuarm@gmail.com>
Date: Thu, 16 Jun 2016 23:23:15 -0400
Links: << >>  << T >>  << A >>
I don't have any trouble getting the simulation (Active HDL) or 
synthesis (Synplify) tools to work with VHDL-2008, but the Lattice tool 
itself doesn't seem to understand it.  When Diamond analyzes the source 
files it complains of syntax errors.  The rest of the tool seems to work 
just fine and this doesn't stop me from completing the project.

I did an Internet search and found a post at eevblog.com about this from 
last year with no response.  I put in a ticket to Lattice.  I am using a 
slightly old version of the tool, 3.3 while the latest is 3.7 I believe. 
  I hope that's not my problem.  lol

-- 

Rick C

Article: 159029
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: David Wade <dave.g4ugm@gmail.com>
Date: Fri, 17 Jun 2016 11:52:06 +0100
Links: << >>  << T >>  << A >>
On 16/06/2016 22:39, GaborSzakacs wrote:
> Jecel wrote:
>
> [snip]
>
>>
>> What I was saying was that I am also interested in FPGA boards with not
>> as much memory and with poorer I/O (VGA and PS/2, for example) than
>> the Pi.
>>
>> -- Jecel
>
> Many low-end FPGA boards are out there, but in general the peripherals
> are richer on the boards with a larger FPGA.  For a bare-bones starter
> board with VGA and USB and PMOD, you could look at:
>
> https://www.nandland.com/goboard/introduction.html
>
> However the ICE40 on that board is not very large for playing with
> embedded processors.
>
> If you can live with HDMI instead of VGA, then possibly the Scarab
> MiniSpartan6+ would be a possibility.  Just be aware that the
> SDRAM on that board is single-data-rate and won't work with the
> built-in hard memory control block of the Spartan-6.
>
> https://www.scarabhardware.com/minispartan6/
>
I have used one of these

http://www.ebay.com/itm/251192875961

for a very small system

Dave
G4UGM

Article: 159030
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Jecel <jecel@merlintec.com>
Date: Fri, 17 Jun 2016 10:37:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rickman,

> > Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
> > it might be enough. Most early microcomputers had 80KB floppy disks.
> 
> I have no idea what you are trying to say with this.  Lots of things 
> were done in the early days of programming including using toggle 
> switches to enter programs.  I don't wish to duplicate any of that.

I am saying some programming environments are pretty small and some embedded
processors are getting large enough that the two can meet. Sure, small can
mean primitive and awkward but not necessarily. I find stuff build around
Eclipse pretty unusable so consider the GB of disk and RAM that they need
a waste.

> I don't know what you are trying to say here.  You mentioned your 
> "SiliconSqueak" which I assume is a processor design.  You seem to be 
> talking about running it on an rPi which doesn't make sense.  Were you 
> just using the rPi as a point of comparison?

Sorry about the confusion. SiliconSqueak is indeed my own processor and
I was talking about implementing it on low end FPGA boards (Gabor and
Dave Wade have just suggested some nice options in this thread) and
comparing their resources with those available on the Raspberry Pi.

The Squeak virtual machine (both the original interpreter and the new
Cog JIT compiler) runs very well on the Raspberry Pi thanks to the
foundation's efforts to make Scratch more usable. This means you can
either run some software on the Pi with these VMs or on an FPGA board
with my processor. That makes comparing the two options interesting,
though an FPGA board costing around $100 might have less resources
than a Pi board costing $5.

-- Jecel

Article: 159031
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Cecil Bayona <cbayona@cbayona.com>
Date: Fri, 17 Jun 2016 12:55:46 -0500
Links: << >>  << T >>  << A >>
On 5/13/2011 7:34 AM, wzab wrote:
> Hi,
>
> I'm very impressed with a J1 forth processor: http://excamera.com/sphinx/fpga-j1.html
> I'd like to use it to implement simple non-time critical control and
> debugging layer
> in my FPGA based DSP system.
> However to accomplish it I need to add possibility of interactive work
> via console
> connected either by UART or by JTAG.
> Has anybody tried to extend the J1 published in http://excamera.com/files/j1demo.tar.gz
> with possibility to interactively define new words and execute them?
> --
> TIA & Regards,
> WZab
>
Its king of a round way to what you want, but the following is 
interesting and might accomplish what you wish.

The ep16 CPU contains within it's zip file the following;

weForth - a Windows version of eForth used to create a development system.
Meta compiler - for the ep16 but easily modified for other stack machines
eForth source - not in assembler but in Forth primitives  be 
meta-compile into the target CPU
Documentation - not just for the CPU, and more importantly for the software.

This package will result in a copy of eForth that would be resident in 
the target CPU

I am working with the ep32 which comes with the same software to learn 
VHDL, my next target is the ep16, followed by the J1, when I get there I 
will be modifying the target compiler to generate J1 primitives and in 
so doing ending with a copy of eForth that resides inside the J1. You 
can wait until I get there or you can Download the code for the ep16 and 
modify it yourself.

Theoretically the J1 has many new instructions built in without changing 
the FPGA code, you would have to add the extra instructions that are 
already there but nor used to the metacompiler software, it looks like 
it's a relatively simple task.

Have fun going Forth.

-- 
Cecil - k5nwa

Article: 159032
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: rickman <gnuarm@gmail.com>
Date: Sat, 18 Jun 2016 12:46:47 -0400
Links: << >>  << T >>  << A >>
On 6/17/2016 1:37 PM, Jecel wrote:
> Rickman,
>
>>> Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
>>> it might be enough. Most early microcomputers had 80KB floppy disks.
>>
>> I have no idea what you are trying to say with this.  Lots of things
>> were done in the early days of programming including using toggle
>> switches to enter programs.  I don't wish to duplicate any of that.
>
> I am saying some programming environments are pretty small and some embedded
> processors are getting large enough that the two can meet. Sure, small can
> mean primitive and awkward but not necessarily. I find stuff build around
> Eclipse pretty unusable so consider the GB of disk and RAM that they need
> a waste.

I have no idea why you are bringing Eclipse into a Forth discussion.

Programming from a PC is the easiest way to work unless your target is 
heavy enough to support an operating system.  So in the Raspberry Pi I 
program directly on the target.  Any embedded board, even with an on 
board Forth compiler, the PC gets used as the host for most development 
work while debugging is on the target.  I load the code which is one 
command and takes maybe a second.  I test a few words or word from the 
command line until I find a bug and make changes.  I forget the stuff 
just loaded, load the new code and in less than 5 seconds I'm back to 
debugging.  Hardly an onerous cycle.  In fact, I barely know I'm working 
from my laptop on a remote target until I get the target locked up and 
have to walk to the other room to push the reset.


>> I don't know what you are trying to say here.  You mentioned your
>> "SiliconSqueak" which I assume is a processor design.  You seem to be
>> talking about running it on an rPi which doesn't make sense.  Were you
>> just using the rPi as a point of comparison?
>
> Sorry about the confusion. SiliconSqueak is indeed my own processor and
> I was talking about implementing it on low end FPGA boards (Gabor and
> Dave Wade have just suggested some nice options in this thread) and
> comparing their resources with those available on the Raspberry Pi.

I haven't spent much time looking at FPGA boards.  I build products with 
FPGA but they are seldom on boards that would support other than fairly 
primitive processors that are doing simple control functions.  My 
current product does not have a processor, but the FPGA is maxed out. 
The FPGA is also obsolete and eventually the board will need to be 
redesigned.  When this happens the code will need to be ported and some 
of the slow speed stuff might be better in a soft CPU.


> The Squeak virtual machine (both the original interpreter and the new
> Cog JIT compiler) runs very well on the Raspberry Pi thanks to the
> foundation's efforts to make Scratch more usable. This means you can
> either run some software on the Pi with these VMs or on an FPGA board
> with my processor. That makes comparing the two options interesting,
> though an FPGA board costing around $100 might have less resources
> than a Pi board costing $5.

If I thought anyone was interested and could find a software guy to team 
up with, I would produce an FPGA board which connected to the fast 
interfaces on a CPU like the rPi or maybe a BeagleBone and use the 
resources on the processor board as a low cost I/O processor for the 
FPGA.  That reminds me of the array processor I used to work on that had 
a compute head on one board and the entire rest of the two rack cabinets 
(including two 68010 processors) were support to get data in and out of 
the compute head.

-- 

Rick C

Article: 159033
Subject: Re: Active HDL Generic Controls
From: Cecil Bayona <cbayona@cbayona.com>
Date: Sat, 18 Jun 2016 14:44:57 -0500
Links: << >>  << T >>  << A >>
On 6/16/2016 4:35 PM, rickman wrote:
> I am working with Active HDL and I'm pretty sure in the past I was able
> to set generics at the top level from within the simulator.  I see in
> the Design, Settings dialog box they have a Simulation,
> Generic/Parameters choice which looks like it should display design
> generics, but I can't see them.  The help file talks about editing these
> items, but I see no editing controls either.
>
> Anyone know what I'm doing wrong?
>
Not a clue, I'm about to install MyDHL on a virtual Windows 7 PC that is 
used to work with FPGAs, it's the final piece of software before I 
declare the image finished, I will have one with Lattice Diamond, and a 
second one with Xilinx Vivado.

I wish that Lattice had more powerful inexpensive board, but they go 
from $43 for the Brevia2 to very expensive boards, It would be nice to 
just have one development system.

-- 
Cecil - k5nwa

Article: 159034
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Jecel <jecel@merlintec.com>
Date: Sat, 18 Jun 2016 16:45:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rick,

sorry that I am not addressing the rest of your post, but I think we
have both said all there is to be said about the subject and won't
reach an agreement.

> If I thought anyone was interested and could find a software guy to team 
> up with, I would produce an FPGA board which connected to the fast 
> interfaces on a CPU like the rPi or maybe a BeagleBone and use the 
> resources on the processor board as a low cost I/O processor for the 
> FPGA.  That reminds me of the array processor I used to work on that had 
> a compute head on one board and the entire rest of the two rack cabinets 
> (including two 68010 processors) were support to get data in and out of 
> the compute head.

While perhaps not using the fast interfaces, there are FPGA expansions
for the boards you mentioned:

http://www.bugblat.com/products/pif/

http://valentfx.com/logi-pi/

http://valentfx.com/logi-bone/

The way to have the fastest possible interface between the FPGA and
the processor is to use a chip like the Xilinx Zynq, which includes
two ARM cores. There are many variations of the Zed board with this
chip:

http://zedboard.org/

The one most like what you were describing is probably the Parallella
board, which is essentially a Zed board in a Raspberry Pi form factor
plus an Epiphany chip with 16 (or 64) floating pointer processors:

https://www.parallella.org/

-- Jecel

Article: 159035
Subject: Re: Active HDL Generic Controls
From: rickman <gnuarm@gmail.com>
Date: Sat, 18 Jun 2016 21:41:42 -0400
Links: << >>  << T >>  << A >>
On 6/18/2016 3:44 PM, Cecil Bayona wrote:
> On 6/16/2016 4:35 PM, rickman wrote:
>> I am working with Active HDL and I'm pretty sure in the past I was able
>> to set generics at the top level from within the simulator.  I see in
>> the Design, Settings dialog box they have a Simulation,
>> Generic/Parameters choice which looks like it should display design
>> generics, but I can't see them.  The help file talks about editing these
>> items, but I see no editing controls either.
>>
>> Anyone know what I'm doing wrong?
>>
> Not a clue, I'm about to install MyDHL on a virtual Windows 7 PC that is
> used to work with FPGAs, it's the final piece of software before I
> declare the image finished, I will have one with Lattice Diamond, and a
> second one with Xilinx Vivado.
>
> I wish that Lattice had more powerful inexpensive board, but they go
> from $43 for the Brevia2 to very expensive boards, It would be nice to
> just have one development system.

What would you like to see on the board?

-- 

Rick C

Article: 159036
Subject: Re: Active HDL Generic Controls
From: Cecil Bayona <cbayona@cbayona.com>
Date: Sat, 18 Jun 2016 22:13:35 -0500
Links: << >>  << T >>  << A >>
On 6/18/2016 8:41 PM, rickman wrote:
> On 6/18/2016 3:44 PM, Cecil Bayona wrote:
>> On 6/16/2016 4:35 PM, rickman wrote:
>>> I am working with Active HDL and I'm pretty sure in the past I was able
>>> to set generics at the top level from within the simulator.  I see in
>>> the Design, Settings dialog box they have a Simulation,
>>> Generic/Parameters choice which looks like it should display design
>>> generics, but I can't see them.  The help file talks about editing these
>>> items, but I see no editing controls either.
>>>
>>> Anyone know what I'm doing wrong?
>>>
>> Not a clue, I'm about to install MyDHL on a virtual Windows 7 PC that is
>> used to work with FPGAs, it's the final piece of software before I
>> declare the image finished, I will have one with Lattice Diamond, and a
>> second one with Xilinx Vivado.
>>
>> I wish that Lattice had more powerful inexpensive board, but they go
>> from $43 for the Brevia2 to very expensive boards, It would be nice to
>> just have one development system.
>
> What would you like to see on the board?
>
A little bigger FPGA, the current one is the smallest in the family so 
it can have more internal RAM and in some CPUs more LUTs doesn't hurt, 
32 bit wide fast external static RAM.

Mind you, the Brevia2 you is a very nice board for $43, the device has a 
few DSP slices, instant on, built in hard devices, SIO, I2C, and a 
timer/PWM device, 128KB of 8 bit wide external SRAM, you can implement 
simple and not so simple Stack based CPUs, but the built in RAM is kind 
of thin, and the external RAM is only 8 bits wide so it makes things 
messy if you need more RAM.

You can get some nice deals from China but they are Xilinx or Altera 
boards, I was looking and there are some nice and fast RAM chips that 
are 16 wide, two of them and you have 32 bit SRAM, so later a plug in 
board might be handy, and might be something I could sell. But right now 
I have too many things going on to tackle that project. There is one 
good deal from Xilinx that you don't have to buy from China, the Arty, 
using the Artix7 chip, 20K LUTs so it can handle more complex projects, 
240KB of internal RAM, and 256MB of 16 bit wide DDR3 RAM, 450MHz 
internal speed for $99

-- 
Cecil - k5nwa

Article: 159037
Subject: Re: Active HDL Generic Controls
From: rickman <gnuarm@gmail.com>
Date: Sat, 18 Jun 2016 23:25:02 -0400
Links: << >>  << T >>  << A >>
On 6/18/2016 11:13 PM, Cecil Bayona wrote:
> On 6/18/2016 8:41 PM, rickman wrote:
>> On 6/18/2016 3:44 PM, Cecil Bayona wrote:
>>> On 6/16/2016 4:35 PM, rickman wrote:
>>>> I am working with Active HDL and I'm pretty sure in the past I was able
>>>> to set generics at the top level from within the simulator.  I see in
>>>> the Design, Settings dialog box they have a Simulation,
>>>> Generic/Parameters choice which looks like it should display design
>>>> generics, but I can't see them.  The help file talks about editing
>>>> these
>>>> items, but I see no editing controls either.
>>>>
>>>> Anyone know what I'm doing wrong?
>>>>
>>> Not a clue, I'm about to install MyDHL on a virtual Windows 7 PC that is
>>> used to work with FPGAs, it's the final piece of software before I
>>> declare the image finished, I will have one with Lattice Diamond, and a
>>> second one with Xilinx Vivado.
>>>
>>> I wish that Lattice had more powerful inexpensive board, but they go
>>> from $43 for the Brevia2 to very expensive boards, It would be nice to
>>> just have one development system.
>>
>> What would you like to see on the board?
>>
> A little bigger FPGA, the current one is the smallest in the family so
> it can have more internal RAM and in some CPUs more LUTs doesn't hurt,
> 32 bit wide fast external static RAM.
>
> Mind you, the Brevia2 you is a very nice board for $43, the device has a
> few DSP slices, instant on, built in hard devices, SIO, I2C, and a
> timer/PWM device, 128KB of 8 bit wide external SRAM, you can implement
> simple and not so simple Stack based CPUs, but the built in RAM is kind
> of thin, and the external RAM is only 8 bits wide so it makes things
> messy if you need more RAM.
>
> You can get some nice deals from China but they are Xilinx or Altera
> boards, I was looking and there are some nice and fast RAM chips that
> are 16 wide, two of them and you have 32 bit SRAM, so later a plug in
> board might be handy, and might be something I could sell. But right now
> I have too many things going on to tackle that project. There is one
> good deal from Xilinx that you don't have to buy from China, the Arty,
> using the Artix7 chip, 20K LUTs so it can handle more complex projects,
> 240KB of internal RAM, and 256MB of 16 bit wide DDR3 RAM, 450MHz
> internal speed for $99

I'm not clear on your response.  The only thing you would like to see is 
a larger FPGA and faster, wider RAM?

-- 

Rick C

Article: 159038
Subject: Re: Active HDL Generic Controls
From: Cecil Bayona <cbayona@cbayona.com>
Date: Sun, 19 Jun 2016 00:36:15 -0500
Links: << >>  << T >>  << A >>
On 6/18/2016 10:25 PM, rickman wrote:
> On 6/18/2016 11:13 PM, Cecil Bayona wrote:
>> On 6/18/2016 8:41 PM, rickman wrote:
>>> On 6/18/2016 3:44 PM, Cecil Bayona wrote:
>>>> On 6/16/2016 4:35 PM, rickman wrote:
>>>>> I am working with Active HDL and I'm pretty sure in the past I was
>>>>> able
>>>>> to set generics at the top level from within the simulator.  I see in
>>>>> the Design, Settings dialog box they have a Simulation,
>>>>> Generic/Parameters choice which looks like it should display design
>>>>> generics, but I can't see them.  The help file talks about editing
>>>>> these
>>>>> items, but I see no editing controls either.
>>>>>
>>>>> Anyone know what I'm doing wrong?
>>>>>
>>>> Not a clue, I'm about to install MyDHL on a virtual Windows 7 PC
>>>> that is
>>>> used to work with FPGAs, it's the final piece of software before I
>>>> declare the image finished, I will have one with Lattice Diamond, and a
>>>> second one with Xilinx Vivado.
>>>>
>>>> I wish that Lattice had more powerful inexpensive board, but they go
>>>> from $43 for the Brevia2 to very expensive boards, It would be nice to
>>>> just have one development system.
>>>
>>> What would you like to see on the board?
>>>
>> A little bigger FPGA, the current one is the smallest in the family so
>> it can have more internal RAM and in some CPUs more LUTs doesn't hurt,
>> 32 bit wide fast external static RAM.
>>
>> Mind you, the Brevia2 you is a very nice board for $43, the device has a
>> few DSP slices, instant on, built in hard devices, SIO, I2C, and a
>> timer/PWM device, 128KB of 8 bit wide external SRAM, you can implement
>> simple and not so simple Stack based CPUs, but the built in RAM is kind
>> of thin, and the external RAM is only 8 bits wide so it makes things
>> messy if you need more RAM.
>>
>> You can get some nice deals from China but they are Xilinx or Altera
>> boards, I was looking and there are some nice and fast RAM chips that
>> are 16 wide, two of them and you have 32 bit SRAM, so later a plug in
>> board might be handy, and might be something I could sell. But right now
>> I have too many things going on to tackle that project. There is one
>> good deal from Xilinx that you don't have to buy from China, the Arty,
>> using the Artix7 chip, 20K LUTs so it can handle more complex projects,
>> 240KB of internal RAM, and 256MB of 16 bit wide DDR3 RAM, 450MHz
>> internal speed for $99
>
> I'm not clear on your response.  The only thing you would like to see is
> a larger FPGA and faster, wider RAM?
>
Yes, although the Brevia2 is not slow, but 32bit fast SRAM and a larger 
FPGA version of it would be great if available for a reasonable price.

Now in case the "Wish Fairy" is listening I would not mind a brand new 
Forrester, and a 50" 4K monitor.

-- 
Cecil - k5nwa

Article: 159039
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Matthias Koch <matthias.koch@hot.uni-hannover.de>
Date: Wed, 22 Jun 2016 17:30:18 +0200
Links: << >>  << T >>  << A >>

>> The J1 can't address much memory, so a native Forth is possible but would
>> be a tight fit.
> 
> I don't recall the limitation, but I would expect it to be on the order 
> of many KB.  Mecrisp is not so large and in fact, I'm pretty sure it has 
> been ported to the J1.  I seem to recall this was done using an open 
> source package (the only one I've ever heard of) that compiles to a bit 
> stream.  In a fit of enthusiasm I believe Matthias Koch ported his Forth 
> to this target making the entire effort open source.  I can't recall for 
> sure, but I'm pretty sure the hardware is also open source.

Exactly, Swapforth by James Bowman and my descendant Mecrisp-Ice with
optimisations run happily in HX1K FPGAs, Icestick and Nandland Go are supported.

If you wish to add more opcodes to the CPU or need gates for something else,
you should go for the HX8K breakout board instead.

Matthias

Article: 159040
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Cecil Bayona <cbayona@cbayona.com>
Date: Fri, 24 Jun 2016 14:20:32 -0500
Links: << >>  << T >>  << A >>
On 5/13/2011 7:34 AM, wzab wrote:
> Hi,
>
> I'm very impressed with a J1 forth processor: http://excamera.com/sphinx/fpga-j1.html
> I'd like to use it to implement simple non-time critical control and
> debugging layer
> in my FPGA based DSP system.
> However to accomplish it I need to add possibility of interactive work
> via console
> connected either by UART or by JTAG.
> Has anybody tried to extend the J1 published in http://excamera.com/files/j1demo.tar.gz
> with possibility to interactively define new words and execute them?
> --
> TIA & Regards,
> WZab
>
I have the ep8080, the ep16, and ep32 cores now working along with a 
resident version of eForth in each of those CPUs, the next CPU will be 
the J1 but first I will need to take a slight detour.

I will continue working on the ep32 core for a while as a learning 
vehicle to learn VHDL, so after some minor upgrades such as adding an 
additional address register, and additional instructions, when I feel 
comfortable with VHDL I will proceed to the J1 CPU.

The first step will be to create a J1 Meta-compiler so I can create a J1 
version of eForth that resides in the J1 CPU. If by then you do not have 
a resident Forth compiler you might be interested in the J1 native 
version of eForth. Once that is working with the existing J1 CPU Verilog 
code, I will proceed to create a version of the J1 in VHDL.

If you are interested let me know and I can do the above in a slightly 
different order, but no matter what I will need to learn VHDL first as 
the  J1 is written in Verilog for a different FPGA than the ones I have so.

Maybe all the above is not necessary as there is a native eForth 
implementation available that I just found. Along with it is code to 
implement a serial port so the J1 can talk to the outside world.

<  https://github.com/samawati/j1eforth  >

-- 
Cecil - k5nwa

Article: 159041
Subject: Problem with Lattice Diamond IPExpress software.
From: Cecil Bayona <cbayona@cbayona.com>
Date: Wed, 29 Jun 2016 10:08:36 -0500
Links: << >>  << T >>  << A >>
Not sure what to make of this problem, I am having IPexpress in Lattice 
Diamond generate a corrupted file if I define a RAM module for use with 
a soft CPU. I have a copy of the original generated file, but when I try 
to generate myself following the documentation, the file generated 
differs from the original by two words in the area of loading data into 
the RAM.

I have three soft CPUs that I have used IPexpress to generate the RAM 
module, and only one project has the problem, a project to create the 
ep16 soft CPU.

I tried after verifying in the manual that I had the right parameters 
when using IPexpress to create a new ram_memory.vhd file, below are some 
observations and steps taken to try to fix the problem;

1. The problem occurs only with the ep16 processor project.

2. From the latest version of Diamond 3.7.1 to version 1.4 and every 
version in between, they all have the same problem, there is a two word 
difference in the code between the original ram_memory.vhd file and the 
newly generated file. If those two words are not corrected, the loaded 
eForth software crashes.

3. The original ep16BIN.mem (binary image of the software), and a newly 
created copy are identical, so that is not the problem.

4. I looked on how one defines the ep16BIN.mem file and the method seems 
correct, the only difference I saw was the ep16BIN.mem file generated 
for the ep16 says that memory entries are 32 bits which is not correct, 
it should be 16 bits, but even after changing it, it still creates a 
ram_memory.vhd file with two wrong words.

5. The problem does not show up on the ep32, or PDP1 projects, it only 
has a problem on the ep16 project.

6. I went and created two new ep16 projects from scratch and the same 
thing happens.

7. I tried running the Lattice software in Windows 10, and Windows 7 and 
there is no difference.

8 If one uses the original ram_memory.vhd or a newly generated version 
with the two words corrections then all versions of Diamond create a 
working project, in both cases I use the same binary image of the software.

I'm going to have to think about this as I'm out of ideas at the 
present, If you have any ideas they would be welcomed.

I do need to figure out what is going on because I want to make changes 
to the ep16, ep32, and eventually work on the J1 CPU which involve 
making changes to the RAM module and I need to have reliable 
ram_memory.vhd file generated as I wont have anything to compare it to.

Thanks for putting up with a long post.
-- 
Cecil - k5nwa

Article: 159042
Subject: need some help with altera quartus
From: kristoff <kristoff@skypro.be>
Date: Wed, 6 Jul 2016 00:03:04 +0200
Links: << >>  << T >>  << A >>
Hi all,


To learn VHDL and FPGAs, I bought a number of boards, one of them being 
this one: 
http://www.aliexpress.com/item/EP4CE10-altera-fpga-board-fpga-development-board-fpga-altera-board-fpga-development-board/32637947021.html

It's a Altera cyclone IV with 16 Mbit of serial flash (M25P16/EPSC16) to 
store the configuration file.

Next to that, I have a USB Blaster.



Now, I am able to create a "blinky" test design and program the device 
using the "jtag" programming mode, but -of course- in this senario the 
configuration is lost after a reset or power-cycle.


Can somebody explain how exactly to program this device so that the 
configuration is stored inthe serial flash device?


Sofar, I found that
- in the programmer, you can add a flash-device to the fpga chip
- there are things called "secundary programing files" and there is an 
option "convert programming files" under the "files"-menu.

But, for the rest, the more I read quarus help website, the less I 
understand this all. The number of files and options there exists only 
seams to go up and -as we say in dutch- it's become very hard to see the 
forest through the trees. :-(


Can somebody give a little more information what exactly I need for 
this? Exactly what file do I need to create?


Any help is welcome!



Cheerio! Kr. Bonne


Article: 159043
Subject: Re: need some help with altera quartus
From: Anssi Saari <as@sci.fi>
Date: Wed, 06 Jul 2016 10:59:34 +0300
Links: << >>  << T >>  << A >>
kristoff <kristoff@skypro.be> writes:

> Can somebody give a little more information what exactly I need for
> this? Exactly what file do I need to create?

From memory (since I haven't done this in a while) you need a .jic file
and you create that from your .sof file in the "convert programming
files" dialog. You need to specify the flash type as well and as I
recall, the UI isn't very intuitive. I think I have a script somewhere
which does it on the command line, easier to share on Usenet...

Article: 159044
Subject: Re: need some help with altera quartus
From: Andy Bennet <andyb@andy.com>
Date: Wed, 6 Jul 2016 09:08:02 +0100
Links: << >>  << T >>  << A >>
On 05/07/2016 23:03, kristoff wrote:
> Hi all,
>
>
> To learn VHDL and FPGAs, I bought a number of boards, one of them being
> this one:
> http://www.aliexpress.com/item/EP4CE10-altera-fpga-board-fpga-development-board-fpga-altera-board-fpga-development-board/32637947021.html
>
>
> It's a Altera cyclone IV with 16 Mbit of serial flash (M25P16/EPSC16) to
> store the configuration file.
>
> Next to that, I have a USB Blaster.
>
>
>
> Now, I am able to create a "blinky" test design and program the device
> using the "jtag" programming mode, but -of course- in this senario the
> configuration is lost after a reset or power-cycle.
>
>
> Can somebody explain how exactly to program this device so that the
> configuration is stored inthe serial flash device?
>
>
> Sofar, I found that
> - in the programmer, you can add a flash-device to the fpga chip
> - there are things called "secundary programing files" and there is an
> option "convert programming files" under the "files"-menu.
>
> But, for the rest, the more I read quarus help website, the less I
> understand this all. The number of files and options there exists only
> seams to go up and -as we say in dutch- it's become very hard to see the
> forest through the trees. :-(
>
>
> Can somebody give a little more information what exactly I need for
> this? Exactly what file do I need to create?
>
>
> Any help is welcome!
>
>
>
> Cheerio! Kr. Bonne
>

You need to attach a serial flash loader to your design, this interfaces 
the jtag socket to your flash device. In the serial flash loader 
megawizard do not tick Share ASMI interface or Use enhanced mode SFL 
boxes. Connect the noe_in pin on the instatiated loader to vcc (this 
should be the only pin.

To program the device you need to generate a *.jlc file using the 
quartus file convertor.

Hope that helps

Andy

Article: 159045
Subject: Re: need some help with altera quartus
From: kristoff <kristoff@skypro.be>
Date: Wed, 6 Jul 2016 21:47:20 +0200
Links: << >>  << T >>  << A >>
Andy, Anssi,





On 06-07-16 10:08, Andy Bennet wrote:
>> Can somebody explain how exactly to program this device so that the
>> configuration is stored inthe serial flash device?
(...)
> You need to attach a serial flash loader to your design, this interfaces
> the jtag socket to your flash device. In the serial flash loader
> megawizard do not tick Share ASMI interface or Use enhanced mode SFL
> boxes. Connect the noe_in pin on the instatiated loader to vcc (this
> should be the only pin.
> To program the device you need to generate a *.jlc file using the
> quartus file convertor.


Both thanks for replying.  It really helps to know at least what file 
you need to create :-)


to sum it all up (for the archive of this NG, if somebody else might 
have the same issue).

I managed to do it like this:
- synthesis the VHDL design -> this creates a .sof file in the 
"output_files" directory

- file -> convert programming files
programming-type = .jic
configuration-device = (in my case) epcs16
input-files:
	flash-loader -> click on "add device" -> select your fpga (in my case) 
ep4ce10
	sof data -> click on "add file" -> select your .sof file
click on "generate" and then "close"

- go to the programmer:
choice "add file" -> select the .jic file

Then program as normal.


Pff!

(I think I'll just program it in memory. That is a lot faster!).



> Hope that helps
It sure did. Thanks!



> Andy
Cheerio! Kr. Bonne.

Article: 159046
Subject: Re: Lattice Diamond and VHDL-2008
From: rickman <gnuarm@gmail.com>
Date: Thu, 7 Jul 2016 11:29:58 -0400
Links: << >>  << T >>  << A >>
On 6/16/2016 11:23 PM, rickman wrote:
> I don't have any trouble getting the simulation (Active HDL) or
> synthesis (Synplify) tools to work with VHDL-2008, but the Lattice tool
> itself doesn't seem to understand it.  When Diamond analyzes the source
> files it complains of syntax errors.  The rest of the tool seems to work
> just fine and this doesn't stop me from completing the project.
>
> I did an Internet search and found a post at eevblog.com about this from
> last year with no response.  I put in a ticket to Lattice.  I am using a
> slightly old version of the tool, 3.3 while the latest is 3.7 I believe.
>  I hope that's not my problem.  lol

Wow!  This has been dragging out for a bit.  They replied saying the LSE 
tool can be set for VHDL-2008.  I wrote back that I don't have a setting 
for LSE.  They sent me a screen shot showing the setting in a dialog 
box.  I sent back a screen shot showing the same dialog box in my tool 
that doesn't have the LSE setting.  I've downloaded the most recent 
version of the tools and installed them before doing this.

Regardless, I'm not sure that LSE is the right setting.  That's an 
alternative synthesis tool, right, "Lattice Synthesis Engine"?  Is that 
what they use to parse the source when the design is "refreshed"?

Meanwhile, I also asked if the bitstream files were the same for the 
LFXP3E-3TN100C and LFXP3C-3TN100C and they said I should re-generate the 
bitstream.  The only difference should be that one uses an external 1.2 
volt core supply and the other has internal LDOs to work off 3.3 volts. 
Would that really result in any difference in the bitstream?  I don't 
want to have to regenerate the bitstream since it would require 
re-qualification.  I'm tempted to try it.  I don't have much confidence 
in the support.

-- 

Rick C

Article: 159047
Subject: Re: Lattice Diamond and VHDL-2008
From: GaborSzakacs <gabor@alacron.com>
Date: Fri, 08 Jul 2016 09:57:28 -0400
Links: << >>  << T >>  << A >>
rickman wrote:
> 
> Meanwhile, I also asked if the bitstream files were the same for the 
> LFXP3E-3TN100C and LFXP3C-3TN100C and they said I should re-generate the 
> bitstream.  The only difference should be that one uses an external 1.2 
> volt core supply and the other has internal LDOs to work off 3.3 volts. 
> Would that really result in any difference in the bitstream?  I don't 
> want to have to regenerate the bitstream since it would require 
> re-qualification.  I'm tempted to try it.  I don't have much confidence 
> in the support.
> 

It's certainly worth a try, but if Lattice is anything like Xilinx,
there would be at a minimum a different device ID and the programming
tools would detect the difference and refuse to program the part.

-- 
Gabor

Article: 159048
Subject: Lattice MachXO2 breakout board - replacing FPGA with different one ?
From: Brane2 <brankob@avtomatika.com>
Date: Fri, 8 Jul 2016 09:26:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I have a couple of that neat boards with XO2-7000 and not much else.

I managed to burn the FPGA on one of them and since Farnell didn't have the exact 7000HE model that was on the board, I used 7000HC and bridged VCC so that chips gets 3.3V for core power that it wants.

But now I can't program it through FTDI. I've noticed several variations of the board. Some had XO2-1200 while mine have XO2-7000HE.

Shoould this with pin-compatible chip just work or do I have to have different EEPROM content for FTDI ?

BTW, trivial "blinkenled" example on _this_ board  fails with:

*************
Device#1 LCMXO2-7000HC: Failed to verify the ID 
(Expected: 0x012BD043 Read: 0xFFFFFFFE).

ERROR - Check configuration setup: Unsuccessful.

ERROR: pgr_program failed.

ERROR - Programming failed.
**********

If it doesn't work through FTDI, I'll use ISP cable on it, but it's nuisance...

Article: 159049
Subject: Re: Lattice Diamond and VHDL-2008
From: rickman <gnuarm@gmail.com>
Date: Fri, 8 Jul 2016 14:53:37 -0400
Links: << >>  << T >>  << A >>
On 7/8/2016 9:57 AM, GaborSzakacs wrote:
> rickman wrote:
>>
>> Meanwhile, I also asked if the bitstream files were the same for the
>> LFXP3E-3TN100C and LFXP3C-3TN100C and they said I should re-generate
>> the bitstream.  The only difference should be that one uses an
>> external 1.2 volt core supply and the other has internal LDOs to work
>> off 3.3 volts. Would that really result in any difference in the
>> bitstream?  I don't want to have to regenerate the bitstream since it
>> would require re-qualification.  I'm tempted to try it.  I don't have
>> much confidence in the support.
>>
>
> It's certainly worth a try, but if Lattice is anything like Xilinx,
> there would be at a minimum a different device ID and the programming
> tools would detect the difference and refuse to program the part.

I talked to a local FAE and he said he thought they used the same die 
with different bond out.  I can't get support to acknowledge they use 
the same bit stream, but maybe I can get them to say it is the same die. 
  If so, the ID would have to be the same.

-- 

Rick C



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search