On Fri, 10 Jun 2016 16:11:09 -0500, Cecil Bayona wrote:

> On 6/10/2016 3:54 PM, rickman wrote:
>> On 6/10/2016 2:05 PM, Cecil Bayona wrote:
>>>
>>> The ep16 is next in the short future after that then the J1, and maybe
>>> the PDP11, and who knows what else. Before I move to some of these
>>> processors I need to become more familiar with VHDL as some of these
>>> CPUs such as the PDP11 with be implemented from scratch.
>>>
>>> Let the fun begin.
>>
>> VHDL is not so hard.  Just learn how to infer a register and
>> instantiate a module and you are practically done.  The rest is just
>> logic which can be added to the register code or inferred separately. 
>> Life will be easier if you enable VHDL-2008 in your tools and use those
>> features.
>>
>> If you have any questions you can ask here or maybe comp.lang.vhdl
>> would be good too.
>>
> I will today be starting on the ep32 CPU, later when I get back from
> running errands.
> 
> I setup a virtual Windows 7 PC and have Lattice Diamond and other tools
> loaded and working. I even have the serial port on the Brevia2 board
> running at 115K baud rate so all is ready. I posted about it on this
> topic earlier today.
> 
> Thanks for all the advice, and I will post in the c.l.vhdl when I have
> an issue with not understanding a feature of VHDL. So far looking at
> some books it all seems OK but a lot of details to remember.

I don't even try to remember all the details of C++ (which is my main 
computer language).  I just remember what's possible, and enough terms 
that I can use a book with a good index, or a site with a good search 
engine, and look up what I need to know.

Then I use it, then I forget it again.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

On 6/10/2016 3:54 PM, rickman wrote:
> On 6/10/2016 2:05 PM, Cecil Bayona wrote:
>>
>> The ep16 is next in the short future after that then the J1, and maybe
>> the PDP11, and who knows what else. Before I move to some of these
>> processors I need to become more familiar with VHDL as some of these
>> CPUs such as the PDP11 with be implemented from scratch.
>>
>> Let the fun begin.
>
> VHDL is not so hard.  Just learn how to infer a register and instantiate
> a module and you are practically done.  The rest is just logic which can
> be added to the register code or inferred separately.  Life will be
> easier if you enable VHDL-2008 in your tools and use those features.
>
> If you have any questions you can ask here or maybe comp.lang.vhdl would
> be good too.
>
I will today be starting on the ep32 CPU, later when I get back from 
running errands.

I setup a virtual Windows 7 PC and have Lattice Diamond and other tools 
loaded and working. I even have the serial port on the Brevia2 board 
running at 115K baud rate so all is ready. I posted about it on this 
topic earlier today.

Thanks for all the advice, and I will post in the c.l.vhdl when I have 
an issue with not understanding a feature of VHDL. So far looking at 
some books it all seems OK but a lot of details to remember.

-- 
Cecil - k5nwa

On 6/10/2016 2:05 PM, Cecil Bayona wrote:
>
> The ep16 is next in the short future after that then the J1, and maybe
> the PDP11, and who knows what else. Before I move to some of these
> processors I need to become more familiar with VHDL as some of these
> CPUs such as the PDP11 with be implemented from scratch.
>
> Let the fun begin.

VHDL is not so hard.  Just learn how to infer a register and instantiate 
a module and you are practically done.  The rest is just logic which can 
be added to the register code or inferred separately.  Life will be 
easier if you enable VHDL-2008 in your tools and use those features.

If you have any questions you can ask here or maybe comp.lang.vhdl would 
be good too.

-- 

Rick C

On 5/27/2016 1:00 PM, Cecil Bayona wrote:
> I a retired person with limited resources and I've always been
> interested in CPU design, so now that I have time I wanted to give it a
> go using FPGAs to design simple CPUs.
>
> I would like some advice on several topics, one being which HDL language
> to learn first, although Verilog seems simpler I've read articles that
> encourages beginners to start with VHDL, although it seems more wordy, I
> believe it will help eliminate more dumb mistakes so I'm leaning that
> way. What is your advice?
>
> Another is which logic families/companies make products that are
> inexpensive and have good features useful in creating CPUs and DSP type
> products as I also am interested in Software Defined Radios.
>
> I have purchase for a starter kit a Lattice Brevia2 kit as it was
> inexpensive and has low power consumption, so I assume will be easier to
> use in the beginning. It's a simple device with 5K LUTs which seems to
> be enough for some of the simple processors that I'm interested in to
> start with, CPUs such as the J1 for starters. From some time back I've
> have a Xilinx Spartan 3 Started kit that I have not used, I plan to use
> it later for more complex designs.
>
> Your opinions and advice is welcomed.

I have been doing a lot of research and have come up with a plan.

I have already implemented the ep8080, a high efficiency I8080 CPU a 
processor that I worked with for many years in my line of work, we 
quickly converted to the I8085 since it's hardware was more efficient, 
and could run at a much higher clock rate. In any case I'm ready to move on.

After some deliberation and tool searching, I have decided to implement 
C H Tings ep32 processor as the next CPU, there are several reasons why, 
some are below;

1. It's a simple tested 32 bit Forth CPU, something I desire, not a work 
in progress.
2. It's implemented on a Brevia2 board, which I already own.
3. I have quite a bit of documentation on it, supplied by C H Ting, and 
it's quite good.
4. I have a Forth assembler, and compiler that generates machine code, 
with documentation.
5. I have the source to a resident eForth compiler for the CPU, with 
documentation.
6. It is written in VHDL which is the first language I want to learn.
7. I has room in the opcodes to add many new instructions.
8. It can pack multiple instructions in an instruction word to make it 
more efficient.
9. Large address space so I could use the external RAM to add program space.

So there are a lot of advantages in the design with room for me to add 
instructions, and make architectural changes. I will start trying to get 
it working this evening after I get all my day activities all done. I've 
setup a virtual W7 partition with VMware Player 12, with all the 
development software and it all seems to work just fine, including the 
serial port working fine at 115K baud rate.

The ep16 is next in the short future after that then the J1, and maybe 
the PDP11, and who knows what else. Before I move to some of these 
processors I need to become more familiar with VHDL as some of these 
CPUs such as the PDP11 with be implemented from scratch.

Let the fun begin.

-- 
Cecil - k5nwa

On Friday, June 3, 2016 at 10:27:07 PM UTC-4, Rick C. Hodgin wrote:
> I was able to go through this tonight.  This type of design is very
> similar to what I plan for my Logician software:
> 
>     http://blog.bastelhalde.de/?p=678
> 
> I modified it so that the input buttons also map to additional LEDs,
> one each for the four inputs, to signal when they are pressed.  But,
> I could not figure out how to do it without going through a dual
> inverter sequence.  When I pulled the signal directly from the input
> pin, it would synthesize without error, but it would not illuminate
> the LED.  I had to route it through the first inverter, then the second,
> and I'm sure about why that is.
> 
> I'd like to begin working with timing and go through the stages to
> get a 640x480 VGA output working with an 8x6 font.  Then, get a second
> Brevia2 to drive the VGA as a stand-alone hardware device communicating
> graphics updates over a simple protocol, allowing for dual-ported memory
> writes (one to SRAM, one to Video-RAM).

I am presently hampered (to the point of significant failure) by knowing
what I want to do, but not knowing the syntax to do it in Verilog (or VHDL).
I'm tempted to begin working on my Logician tool so I can create its UI to
operate the way I think. :-)

Best regards,
Rick C. Hodgin

On 6/4/2016 8:17 AM, Marko Zec wrote:
> Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
>> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>>> I think it's chip select.  It looks like there are 17 address pins.  2^17
>>> yields 128 KB.  The data reads/writes are 8-bits each, so I presume I will
>>> be reading/writing 8 bits at that byte-address.  2^17 * 8 = 1 MBit.  The
>>> specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
>>> could be thought of essentially as the 18th address pin?
>>
>> CS is chip select.  It's typically connected to the rest of your address
>> decode logic: when you know you're talking to this chip and not something
>> else, assert CS.
>>
>> However this is likely to be asynchronous SRAM, so the timing of CS and OE or
>> WE set up the read or write cycle.  I don't know the chip they use, but this
>> is the datasheet for a traditional 'old fashioned' SRAM:
>> http://6502.org/users/alexis/62256.pdf
>> - see page 8.
>>
>> Since there isn't a clock going to the SRAM, you need to generate a cycle
>> that meets the timing diagram from the chip you have.  That means asserting
>> signals in the right order and waiting the right length of time before you
>> latch in any read data.  Since the SRAM has no maximum time for an access
>> cycle, you can just take it nice and slow by padding extra cycles in
>> whatever clock you happen to use, and it should be fine, but you do still
>> need to obey the right sequence.
>
> I think the particular SRAM chip on the Lattice Brevia 2 board is of the
> true static kind.  However, there are also certain pseudo-SRAM chips
> out there, i.e. DRAMs disguised behind an asynchronous, supposedly
> SRAM-compatible interface, which require CS to be deasserted every
> 15 us or so, in order to trigger DRAM's internal auto-refresh cycles.
> So don't take it for granted that CS is just an old-school chip select
> signal - it may be much more than that, and only digging into the
> datasheet of the particular chip can reveal its CS signal's true nature.
>
> Marko
>
15 ns access time true static RAM chip.
< 
http://www.idt.com/products/memory-logic/srams/asynchronous-srams/71v124-33v-128k-x-8-asynchronous-static-ram-center-power-ground-pinout 
  >

The board is not bad in terms of price ($43 at Mouser) for what you get, 
instant on, 128KB external RAM, 12 18x18 multipliers, 3 DSP Blocks, 
400MHz FPGA core.

Another slightly more expensive but with some extra features is the 
Papilio Duo for about $88 with Spartan 6 FPGA, 512 KB RAM (Optionally 
2MB RAM), 8MB FLASH, that is bytes not bits, Arduino UNO with interface 
connectors, and a FPGA chip with 18 DSPslices.

Too many toys, but not enough time.
-- 
Cecil - k5nwa

Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>> I think it's chip select.  It looks like there are 17 address pins.  2^17
>> yields 128 KB.  The data reads/writes are 8-bits each, so I presume I will
>> be reading/writing 8 bits at that byte-address.  2^17 * 8 = 1 MBit.  The
>> specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
>> could be thought of essentially as the 18th address pin?
> 
> CS is chip select.  It's typically connected to the rest of your address
> decode logic: when you know you're talking to this chip and not something
> else, assert CS.
> 
> However this is likely to be asynchronous SRAM, so the timing of CS and OE or
> WE set up the read or write cycle.  I don't know the chip they use, but this
> is the datasheet for a traditional 'old fashioned' SRAM:
> http://6502.org/users/alexis/62256.pdf
> - see page 8.
> 
> Since there isn't a clock going to the SRAM, you need to generate a cycle
> that meets the timing diagram from the chip you have.  That means asserting
> signals in the right order and waiting the right length of time before you
> latch in any read data.  Since the SRAM has no maximum time for an access
> cycle, you can just take it nice and slow by padding extra cycles in
> whatever clock you happen to use, and it should be fine, but you do still
> need to obey the right sequence.

I think the particular SRAM chip on the Lattice Brevia 2 board is of the
true static kind.  However, there are also certain pseudo-SRAM chips
out there, i.e. DRAMs disguised behind an asynchronous, supposedly
SRAM-compatible interface, which require CS to be deasserted every
15 us or so, in order to trigger DRAM's internal auto-refresh cycles.
So don't take it for granted that CS is just an old-school chip select
signal - it may be much more than that, and only digging into the
datasheet of the particular chip can reveal its CS signal's true nature.

Marko

Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> I think it's chip select.  It looks like there are 17 address pins.  2^17
> yields 128 KB.  The data reads/writes are 8-bits each, so I presume I will
> be reading/writing 8 bits at that byte-address.  2^17 * 8 = 1 MBit.  The
> specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
> could be thought of essentially as the 18th address pin?

CS is chip select.  It's typically connected to the rest of your address
decode logic: when you know you're talking to this chip and not something
else, assert CS.

However this is likely to be asynchronous SRAM, so the timing of CS and OE or
WE set up the read or write cycle.  I don't know the chip they use, but this
is the datasheet for a traditional 'old fashioned' SRAM:
http://6502.org/users/alexis/62256.pdf
- see page 8.

Since there isn't a clock going to the SRAM, you need to generate a cycle
that meets the timing diagram from the chip you have.  That means asserting
signals in the right order and waiting the right length of time before you
latch in any read data.  Since the SRAM has no maximum time for an access
cycle, you can just take it nice and slow by padding extra cycles in
whatever clock you happen to use, and it should be fine, but you do still
need to obey the right sequence.

Theo

On Friday, June 3, 2016 at 6:01:44 PM UTC-4, Cecil Bayona wrote:
> On 6/3/2016 2:46 PM, Rick C. Hodgin wrote:
> > On Friday, June 3, 2016 at 3:42:54 PM UTC-4, Cecil Bayona wrote:
> >> On 6/3/2016 2:29 PM, Rick C. Hodgin wrote:
> >>> Specs:
> >>>
> >>>     http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/JL/LatticeXP2Brevia2DevelopmentKitUsersGuide.PDF?document_id=43735
> >>>
> >>> In looking at the specs, it shows that all five momentary push buttons
> >>> are already debounced, and 3 of the 4 DIP switches are (4 to 5 is not,
> >>> pin 55).
> >>>
> >>> Awesome.  Should make it easier.
> >>>
> >>> What are pins 142, 143, 144 (SRAM_CSb, SRAM_OEb, SRAM_WEb).  I assume
> >>> output enable and write enable?  But what is CS?  Some kind of strobe?
> >>> Do the address and data pins go high, and write goes high, and then
> >>> it's strobed before it actually writes?  Or address pins go high, and
> >>> then output goes high, and then it's strobed before data pins are
> >>> ready?  Or does CS signal when the operation is complete after OE or
> >>> WE go high?
> >>>
> >>> Or are they something else entirely? :-)
> >>
> >> I would not be sure that applies to any application but is what the demo
> >> does, as they do not know what you will end up doing with the I/O pins.
> >
> > I think it's chip select.  It looks like there are 17 address pins.  2^17
> > yields 128 KB.  The data reads/writes are 8-bits each, so I presume I will
> > be reading/writing 8 bits at that byte-address.  2^17 * 8 = 1 MBit.  The
> > specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
> > could be thought of essentially as the 18th address pin?
> >
> > I couldn't find the video with the lessons.  Do you have a link, Cecil?
> >
> > Best regards,
> > Rick C. Hodgin
> >
> 
> Sorry, I forgot to add the link, but mind you the lesson is not for the 
> Lattice board, but it's in VHDL which can be used with any board.
> 
> Lesson 2 has the implementation including debouncing of buttons, and a 
> state machine.
> 
> <  https://www.youtube.com/watch?v=pDE2qenDXKQ  > Lesson 1	Basics
> <  https://www.youtube.com/watch?v=uhxTgUSZvYE  > Lesson 2	Button 
> Debouncer, State Machine
> <  https://www.youtube.com/watch?v=yoytRxOjA-A  > Lesson 3	Oscilloscope, 
> VGA output

I was able to go through this tonight.  This type of design is very
similar to what I plan for my Logician software:

    http://blog.bastelhalde.de/?p=678

I modified it so that the input buttons also map to additional LEDs,
one each for the four inputs, to signal when they are pressed.  But,
I could not figure out how to do it without going through a dual
inverter sequence.  When I pulled the signal directly from the input
pin, it would synthesize without error, but it would not illuminate
the LED.  I had to route it through the first inverter, then the second,
and I'm sure about why that is.

I'd like to begin working with timing and go through the stages to
get a 640x480 VGA output working with an 8x6 font.  Then, get a second
Brevia2 to drive the VGA as a stand-alone hardware device communicating
graphics updates over a simple protocol, allowing for dual-ported memory
writes (one to SRAM, one to Video-RAM).

Best regards,
Rick C. Hodgin

On 6/3/2016 2:46 PM, Rick C. Hodgin wrote:
> On Friday, June 3, 2016 at 3:42:54 PM UTC-4, Cecil Bayona wrote:
>> On 6/3/2016 2:29 PM, Rick C. Hodgin wrote:
>>> Specs:
>>>
>>>     http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/JL/LatticeXP2Brevia2DevelopmentKitUsersGuide.PDF?document_id=43735
>>>
>>> In looking at the specs, it shows that all five momentary push buttons
>>> are already debounced, and 3 of the 4 DIP switches are (4 to 5 is not,
>>> pin 55).
>>>
>>> Awesome.  Should make it easier.
>>>
>>> What are pins 142, 143, 144 (SRAM_CSb, SRAM_OEb, SRAM_WEb).  I assume
>>> output enable and write enable?  But what is CS?  Some kind of strobe?
>>> Do the address and data pins go high, and write goes high, and then
>>> it's strobed before it actually writes?  Or address pins go high, and
>>> then output goes high, and then it's strobed before data pins are
>>> ready?  Or does CS signal when the operation is complete after OE or
>>> WE go high?
>>>
>>> Or are they something else entirely? :-)
>>
>> I would not be sure that applies to any application but is what the demo
>> does, as they do not know what you will end up doing with the I/O pins.
>
> I think it's chip select.  It looks like there are 17 address pins.  2^17
> yields 128 KB.  The data reads/writes are 8-bits each, so I presume I will
> be reading/writing 8 bits at that byte-address.  2^17 * 8 = 1 MBit.  The
> specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
> could be thought of essentially as the 18th address pin?
>
> I couldn't find the video with the lessons.  Do you have a link, Cecil?
>
> Best regards,
> Rick C. Hodgin
>

Sorry, I forgot to add the link, but mind you the lesson is not for the 
Lattice board, but it's in VHDL which can be used with any board.

Lesson 2 has the implementation including debouncing of buttons, and a 
state machine.

<  https://www.youtube.com/watch?v=pDE2qenDXKQ  > Lesson 1	Basics
<  https://www.youtube.com/watch?v=uhxTgUSZvYE  > Lesson 2	Button 
Debouncer, State Machine
<  https://www.youtube.com/watch?v=yoytRxOjA-A  > Lesson 3	Oscilloscope, 
VGA output

-- 
Cecil - k5nwa