On 12/19/07, Kenneth Ostby <[EMAIL PROTECTED]> wrote: > > I started writing a simple SPI wrapper module, which I just committed > to the repository. The file is somewhat big, for sizes of email > readability, so I'll provide you with the link instead[1]. I'll get down > to make it prettier and more correct later today, but I believe the > "logic" should be there for you to see and comment. Amongst others I'm > planning on cleaning up the variable names.
This code is exceptionally clean and readable, and I wish my code always looked this good. This is also exactly what we had in mind. I have two notes for you. One is that you don't have any in-coming data connected to write_data. Instead, you've connected that to the same signal as read_data. But you probably knew that. :) Also, we didn't document the interface for SPI so well, so I need to explain a little. read_cmd, read_dummy_byte (which is itself just a flag), and write_cmd are all configuration options. They're static values that'll be set externally, so they wouldn't to through the fifo; they'd just appear on the interface of the module. Actually, I don't know how we're going to solve this problem in general, since they need to be correct for reading the BIOS prom on boot. For the FPGA, this isn't a problem, but for the ASIC, we may end up having an array of configuration resistors on the PCB or something. Note to the rest of us for when we do the synthesizer configuration files: Those configuration options would be marked as "false paths" so that they're ignored for timing analysis. Makes it easier to P&R everything else that does need to meet some timing requirement. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
