RE: 6809 assembly knowledge needed

Quick observation is that the optimization pass will usually eliminate any unneeded logic and at a level that would take a human a long time to equal. So much so that usually we used to tweak the optimization to leave some things alone so that an actual signal will exist rather than be carried around as subterms, if for no other reason than it was easier to simulate.

When transitioning from discreet logic to fpga I learned not to put priority on preserving registers, at least until I was truly squeezed in the end, in fact a common way to fix complex timing issues was with registers, you start pipelining your ass off to keep combination delays (or the propagation of unknown states due to delays) to a minimum.

There is probably 20 ways to do anything and at least 3 of them can be considered the right way (I.E. there is more than one right answer, depends on design style in the end), I usually concentrate on functionality first, as long as I am not letting things get too crazy with size die to architectural decisions, and then deal with size as a tradeoff between speed and size. When the tradeoff is clarity/readability vs size I come down on the side of clarity first (size later).

Enjoy!  FPGA's are a blast.

Bil

-----Original Message-----
From: owner-cbm-hackers@musoftware.de [mailto:owner-cbm-hackers@musoftware.de] On Behalf Of Jim Brain
Sent: Friday, February 05, 2010 2:01 AM
To: cbm-hackers@musoftware.de
Subject: Re: 6809 assembly knowledge needed

I've been teaching myself Verilog tonight, and I have made the design I
wanted in the language.  Still, it'd be nice to know who on-list might
be able to answer questions, as I have plenty.

What caught me tonight was this:

output wire p1_io1,p1_io2
reg [7:0] config
input wire io1,io2

// allow p1_io1 to go low when selected (config[0] = 0) and io1 is low
and swap (config[2]) is low, or if config[2] is high and config[1] and
io2 are both low

// this works
assign p1_io1 = (CONFIG[0] | io1 | config[2]) & (config[1] | io2 |
!config[2]);

// this does not:
always @(io1 or io2 or config1[2:0]) begin
      case(config1[2])
         1'b0:  begin
             p1_io1 = io1 | config[0];
             p1_io2 = io2 | config[1];
           end
         1'b1:  begin
             p1_io2 = io1 | config[0];
             p1_io1 = io2 | config[1];
           end
      endcase
    end

I thought the latter was easier to read, but to use it, p1_io1 and
p1_io2 have to be declared as reg.  I have a philosophical issue with
that, as I view "reg" as a register, and I don't think the CPLD/FPLGA
needs to dedicate a precious register to the value of p1_io1, etc.  I
see in the documentation/web pages that the tool should determine that
no state is kept, so it will just turn the case statement into
combinatorial logic, but it worries me.

The final solution I used was:

assign p1_io2 = config[2] ? io2 | config[1] : io1 | config[0];

Thanks goodness for Icarus.  I'd have given up trying to learn in the
vendor tools.

To keep things on topic, here's my idea:

I was thinking of adding some smarts to the dumb cart port expander.
Use a CPLD to select/deselect the various control lines, and set the
config via a set of registers that are exposed in IO2 in some temporary
way.  The switches would still be there, but they would represent the
"initial state" of the settings, which can be overriden via SW.

Thoughts?

Jim

--
Jim Brain, Brain Innovations                                      (X)
brain@jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Home: http://www.jbrain.com


       Message was sent through the cbm-hackers mailing list

--
This message has been scanned for viruses and dangerous content by IDSi's  MailScanner.


       Message was sent through the cbm-hackers mailing list