Skip to main content ↑ ↓
Topic: Parts list (rough design, options) (Read 72418 times) previous topic - next topic

Re: Parts list (rough design, options)

Reply #60 –
I've seen this project before, the Sump Java client is much nicer. If I'm not mistaken the Java client for this project just generates a verilog file that you have to load up into Webpack in order to view the waveforms.

Re: Parts list (rough design, options)

Reply #61 –
Exactly, it's more or less intended as an "on-chip" logic analyzer for FPGA projects.

Quote
quoted from the OpenVeriFLA version 1.0.3 Reference Manual:

It helps in on-board testing and debugging of the FPGA projects.
This is done by real-time capturing and then graphically displaying
the signals transitions that happen inside the FPGA chip.

... The java application receives the captured data and saves it on the disk in a
file named capture.v. This file is a behavioural verilog HDL file. An Verilog
HDL simulator with a graphical viewer for the signals is necessary in order to
simulate capture.v and view the captured data.

While the FPGA implementation of the LA logic seems to follow a concept similar to Jacks SUMP LA implementation and even a Java application is used on the PC to receive and convert the captured data, the design is in no way SUMP compatible and relies on the presence of ISE or some other "Verilog HDL simulator with a graphical viewer" on the PC. The project does not appear to be active or well documented - it will take to go through both the Verilog and the Java code to get a full understanding and to make any use of it ...

Re: Parts list (rough design, options)

Reply #62 –
Are you guys trying to just slap this implementation together without any design? From what I can read, Jack didn't design the LA. And It wouldn't be any work to find/design an USB MCU to go with the LA.

[quote author="jack.gassett"]
I've seen this project before, the Sump Java client is much nicer. If I'm not mistaken the Java client for this project just generates a verilog file that you have to load up into Webpack in order to view the waveforms.
[/quote]

Someone could take it and convert it to be SUMP compatible.

I already have a MCU design that we could expand and use, I did it for a Digital Design Project my second semester in College.

[quote author="IPenguin"]
The project does not appear to be active or well documented - it will take to go through both the Verilog and the Java code to get a full understanding and to make any use of it ...
[/quote]

Sounds to me that you're too lazy to take 20 minutes to read the code.

Re: Parts list (rough design, options)

Reply #63 –
... you are right, Jack did not design the "FPGA Based Logic Analyzer". Indeed, some details about the SUMP LA project
got never mentioned in this discussion. Lets pay due respect to those who deserve it (in chronological order)
... along the lines better too late than never ... and use this opportunity to give some essential links as well:

The original Logic Analyzer VHDL model, the Communication Protocol and the Java Logic Analyzer Client were specified,
designed, implemented, documented and made available as an open source project by Michael Poppitz.

The port of the VHDL code to the Spartan-3E Starter Kit was done by Jonas Diemer.

There is even a "Logic Analyser mit Pollin CPLD Board" port for a € 24,95 (~ US$ 37) CPLD evaluation board by befro (?).
Unfortunatley it's all in German, spread over 3 threads and not really documented ...

Oak Micros has improved the Java Client for the SUMP LA and written a great "Logic Analyzer User Guide" for the sump
logic analyzer built around the Digilent Spartan3 FPGA development board, their omla32 interface card, and a Java User
Interface - the files can be downloaded here.

Jack Gassett has ported the SUMP LA design to his Butterfly Platform, implemented some improvements to the LA VHDL
design as well as the SUMP Java Client and prepared some nice tutorials (Jack, please forgive, if I missed something).

Ian came up with the great idea of putting (or you may say "slapping") the SUMP LA design on a very low cost board
(US$ 30-40) and Jack offered his cooperation and support for this project by bringing in the FPGA side of the design
and his experience.

To my knowledge this will be the first application specific implementation of the SUMP Logic Analyzer on a single PCB
that will allow users to get their hands on a low cost, open source, FPGA based logic analyzer they can put to use out
of the box without having to install and get familiar with FPGA development environments and overfeatured FPGA boards.

All comparable previous LA implementations seem to have used standard FPGA evaluation/development boards with
adapter boards (starting at around US$ 100) and relied on (at least parts of) FPGA development environments for
loading the FPGA configuration before the application could be used ...

P.S. ... and yes, you may call me lazy. :D   Most of this information (and far more) can be found on the Logic Analyzer project pages at Jack's Gadget Factory site.

Re: Parts list (rough design, options)

Reply #64 –
Thanks for the project summary, I'll use those links in the eventual project writeup.

RE:documentation - this is somewhere we can excel. I try to keep things well documented, both in terms of the hardware writeup, but also a 'manual' with links to interesting stuff.

Indeed, my methodology is probably best described as 'slapping together'. I refer any complaints to the name of my website :) Just kidding :)
Got a question? Please ask in the forum for the fastest answers.

Re: Parts list (rough design, options)

Reply #65 –
I'm Sorry.

I'm the kind of "engineer" who likes to get things as correct as can be, before sharing what I have. Which I know I don't do sometimes if I'm excited about my particular project.

I'll share what my idea is, and show screenshot and ask for opinion, and yes, everyone's opinion matters to me.

Re: Parts list (rough design, options)

Reply #66 –
I just checked in some updates to the FPGA side. Included is a 16 Bit Wing footprint. I've been toying with the idea of adding an anchor point so that Wings can use standoffs for additional stability. I included the anchor point with the footprint but it can be easily removed if people don't like it.

Re: Parts list (rough design, options)

Reply #67 –
Are the connections to 13...16 on the wing set in stone?

Is it possible to rotate the FPGA so the ROM is closer to the PIC? Right now it looks like the ROM SPI connections will be routed under the primary 8 input pins. I included three scenarios, none seem to be ideal.

Is there a clear or reset pin on the FPGA that the PIC can manipulate to hold the FPGA in reset while the PIC updates the ROM?

I'd like 2 extra connections on the PIC->FPGA serial connection for a possible future update to faster SPI. Since the PIC, ROM, and FPGA already share an SPI connection, could we recycle the ROM connection for the UART/SPI connection? They'll never be in use at the same time, but there might be an issue with garbage data on the PIC UART while the ROM loads unless the FPGA indicates 'ready/loaded' on one of the other pins before we start the UART. For the future SPI connection I thought the FPGA could indicate the end of capture by changing SDI while CS is disabled instead of a dedicated interrupt pin.

Changes:
Separate ground plain for the PIC side
Fixed USB supply pin to 3v3 for 18Fxxjxx PIC VUSB supply style
Changed from 2x3 ROM header to 1x6 header
Added 74xx573 SOIC
Added 1x9 (Saleae logic style) and 2x6 header (cheap ribbon cable)
Renamed IC2A -> IC2
Added pin for FPGA 4 wire connection
Added pin for UART connection
Added pin for vreg enable

I routed some power traces to learn more about the FPGA power supply, please don't consider it anything but a doodle.

What do you think, 9 pin straight header like on the saleae logic (nice cables available), or cheap 2x ribbon cable header?
Got a question? Please ask in the forum for the fastest answers.

Re: Parts list (rough design, options)

Reply #68 –
Jack - I edited your image and added it to the post because it was breaking the page width on my netbook. Sorry about that.
Got a question? Please ask in the forum for the fastest answers.

Re: Parts list (rough design, options)

Reply #69 –
[quote author="ian"]
Is there a clear or reset pin on the FPGA that the PIC can manipulate to hold the FPGA in reset while the PIC updates the ROM?
[/quote]
Pulling the PROG_B pin low tristates the FPGA pins. When it will go high again the FPGA starts its configuration. Figure 54 in the datasheet
describes how to connect an Atmel SPI prom for configuration. It also describes the standard programming header to program the SPI prom
with Impact and a Xilinx Jtag adapter.
[quote author="ian "]
I'd like 2 extra connections on the PIC->FPGA serial connection for a possible future update to faster SPI. Since the PIC, ROM, and FPGA already share an SPI connection, could we recycle the ROM connection for the UART/SPI connection? They'll never be in use at the same time, but there might be an issue with garbage data on the PIC UART while the ROM loads unless the FPGA indicates 'ready/loaded' on one of the other pins before we start the UART.
[/quote]
The Done pin indicates a successful configuration

Re: Parts list (rough design, options)

Reply #70 –
A suggestion, Ian,  how about checking with SEEED  about cases they migh be able to supply for the LA.  This might influence the exact PCB dimensions.  I would hate to have to use a larger case, when a small adjustment now would solve the issue.  
I agree 100% with the idea of minimizing the cost of the base LA.  If I understand the present design, the buffered I/Os have been scaled back from the original 16 to 8.  Might I suggest that the base PCB be layed out for 16 channels but depopulated to 8 for the base offering( no chips / header).  The cost impact on the PCB I would guess be negligible.  In Ian's latest post I think there is room if the buffer IC are slide up a bit .

Re: Parts list (rough design, options)

Reply #71 –
Currently all I/O connections on the FPGA are purely incidental and will be moved and sorted out once we establish all of our desired connections. I will work on cleaning up the incidental connections, once that is done then just make any open connection that you need on the schematic. Since all of the I/O is generally interchangeable we will establish the final connections based on what is easiest to route and the initial schematic connections will just indicate a desired connection. The final schematic design will be corrected to show the correct connections.

I'll play around with some alternative orientations of the FPGA chip that makes the SPI chip more accessible. We need to strike a balance for easy routing of the Power, SPI Flash, and I/O lines. Maybe a 45 degree orientation will make things easier.

Thank you LeissKG for looking up the reset and done pins, I concur that those are the correct pins to do the required job. Hold PROG_B low to put the pins in highZ and program the SPI Flash chip.

Lets do the 9 pin straight header with possibility of nice cables. As long as it does not present a routing challenge.

A nice case would be great, assuming it does not affect the overall cost much. Maybe we can sell a barebones circuit and one with a case for a little more?

Re: Parts list (rough design, options)

Reply #72 –
BTW: All three of those designs are in the SVN.

Thanks so much for the pin names. I'll add those next time I check out the files. I'm not super familiar with FPGA, and I really appreciate the help getting started.

For my 'side', I think I'm going to flip the PIC like in the last image (pumpc). That way I don't have to route the USB signals under or around the 20mhz crystal. That's also the FPGA orientation I like the most, but I don't know how feasible it is. It's unfortunate that the JTAG and ROM pins both stretch over entire sides like that.

It might be possible to route the 2 ROM traces on the bottom layer under the FPGA. They should (might? depends on the pin) both be @ ground when the analyzer is active.

Here's the justification for small steps (and starting with and maintaining open source files):
http://blog.makezine.com/archive/2009/1 ... the_c.html
Got a question? Please ask in the forum for the fastest answers.

Re: Parts list (rough design, options)

Reply #73 –
We can move the oscillator to any global clock input so we have flexibility there. What do you think about getting rid of the JTAG port? That would make routing over an unbroken ground plane much easier.

Re: Parts list (rough design, options)

Reply #74 –
[quote author="jack.gassett"]
We can move the oscillator to any global clock input so we have flexibility there. What do you think about getting rid of the JTAG port? That would make routing over an unbroken ground plane much easier.
[/quote]

For the clocks I would suggest you follow the design note on page 59 of the data sheet.

Design Note
Avoid using global clock input GCLK1 as it is always shared with the M2 mode select pin. Global clock inputs GCLK0,
GCLK2, GCLK3, GCLK12, GCLK13, GCLK14, and GCLK15 have shared functionality in some configuration modes.

If I read Table 55 on page 80 right, the latter clock pins should be no problem in SPI configuration mode

Regarding the JTAG connector i would say omit it only if the design is otherwise impossible. If you have it, you can debug
the LA design inside the FPGA with chipscope if you have a license.


Klaus