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: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Jim Brain Sent: Friday, February 05, 2010 2:01 AM To: email@example.com 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) and io1 is low and swap (config) is low, or if config is high and config and io2 are both low // this works assign p1_io1 = (CONFIG | io1 | config) & (config | io2 | !config); // this does not: always @(io1 or io2 or config1[2:0]) begin case(config1) 1'b0: begin p1_io1 = io1 | config; p1_io2 = io2 | config; end 1'b1: begin p1_io2 = io1 | config; p1_io1 = io2 | config; 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 ? io2 | config : io1 | config; 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) firstname.lastname@example.org 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 listReceived on 2010-02-05 14:00:05
Archive generated by hypermail 2.2.0.