FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Timing

A cheap logic analyzer. Get one for $50, including worldwide shipping. A collaboration between the Gadget Factory and Dangerous Prototypes.

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby dogsbody » Sun May 08, 2011 1:24 am

Updated spec with flubberlab's changes is now posted.

I cleaned up the formatting & tweaked a couple things also. You we're definitely right about it needing a little extra clarity in there.

Same links as before, but I'll repeat them here:
-- Word format (1.1 MB) --
-- PDF format (674 KB) --

Cheers!
-- IED
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby flubberlab » Mon May 09, 2011 4:21 am

Beautiful. Thanks.

How about another little interface revision: The device returns (readCount + 1) * 4 bytes, so perhaps
"The read-count specifies the number of samples (read_count = (num_samples/4) - 1) to be returned to the client on your PC (one byte per each enabled input channel group). The delay-count specifies the number of samples (delay_count = (num_samples/4) - 1) to capture -after- the basic or advanced trigger fires."
flubberlab
Jr. Member
Jr. Member
 
Posts: 50
Joined: Sun Jan 30, 2011 5:44 am
Location: Seattle, WA

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby dogsbody » Mon May 09, 2011 11:55 pm

Hmm... # bytes returned certainly is (readcount+1)*4.

However, the number of -samples- depends on demux mode if I remember right. If you're expecting "x" samples, you need to divide by 4 or 8 depending on demux mode since it samples at 2x rate. Ug.

I'm torn between keeping an relatively easy to understand description for the curious & gory details for developers.

Maybe another appendix would be better. Something with example code...
-- IED
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby flubberlab » Tue May 10, 2011 4:20 am

I know what you mean.

I guess the desired content depends on who the spec is written for. I have considered it first and foremost as an interface spec that targets software developers that need to know precisely what the OLS can do and how to make it do it. Perhaps a useful thought is something like this: if it has a command description that includes the numeric opcode and parameter bitmap, then why not go ahead and describe as precisely and completely as possible what the effect of the command is?

I think the fact that it is such a sweet document tempts one to use it as a user guide as well. In an ideal world, I think there would exist both a programmer's guide (your spec) and a user guide.

The way I look at it is I can probably figure out how to use something with only a programmer's guide, but I can't write software to run it with only a user guide. I'd have to reverse-engineer the thing to do that (i.e. create my own programmer's guide).

Thanks for listening.
flubberlab
Jr. Member
Jr. Member
 
Posts: 50
Joined: Sun Jan 30, 2011 5:44 am
Location: Seattle, WA

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby flubberlab » Tue May 10, 2011 4:47 am

I noticed something unexpected with the 3.07 Basic/Legacy trigger operation that I think is a good candidate to be described in the spec/guide.

I observed that a trigger stage increments the trigger level even though all of its inputs are masked off. Is this the intended behavior? I expected that the level would not be bumped by the stage configured as such.

This lead me to the question "How do you disable one or more stages?" A workaround I used was to arm the unused stages at a level greater than or equal to the arm level of the capture stage/s with the highest arm level.
flubberlab
Jr. Member
Jr. Member
 
Posts: 50
Joined: Sun Jan 30, 2011 5:44 am
Location: Seattle, WA

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby dogsbody » Wed May 11, 2011 4:12 am

A masked off bit is basically always a "match". So if you mask off all bits, then they all match. Thus the trigger stage trips. Not a good way to disable a stage.

There is no explicit way of disabling legacy trigger stages. Setting the start level to 3 is one way of disabling a trigger though.

Another way is not even trying. Simply configure all stages identically on your first trigger. Need a second trigger? Then pick a stage (any stage) & configure it.

The basic trigger isn't a state machine. Any stage can trigger any other. The only thing which matters is the trigger "level", and the level increments whenever any of the stages trips. If one or more trip at the same time, the level only increments once.

This is off the top of my head. To be honest, I don't use the basic trigger much so haven't given this a lot of thought.

If it works, let me know & I'll write it up.
-- IED
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby flubberlab » Wed May 11, 2011 7:36 pm

@dogsbody,

Thanks for your description; it really corrects my false assumptions about how the trigger works (and gives me the luxury of slacking on learning Verilog or VHDL!). I can see why masking off bits is exactly opposite the "right" approach to disable a stage.

Here is what I have learned:
--- The mask and value combine to form the classic (on the analyzers I have used) "0, 1, don't care (X)" pattern choices (pattern 0/1/X = mask:value 1:0/1:1/0:?).
--- All stages are permanently active. Each stage either initiates a capture (if configured to do so) or increments the trigger level regardless of its mask.
--- If multiple stages have duplicate masks/values, the group acts together as if it were a single stage, and increments the trigger level only once. If any stage in a group of duplicate stages is configured to initiate a capture, then a capture will be initiated exactly once.

I think your idea of duplicating stages is clearly sound, whereas my idea of relying on setting the arm levels "out of range", is not (to me) obviously--without further analysis--effective for all possible cases.

Duplicating the triggers as you describe works in this simple application I tried. Here are some examples (capture on low to high edge) that illustrate what works and does not:

Stage Level Pattern Capture?
1 0 0 No
2 1 1 Yes
3 3 X No
4 3 X No
Does work, since desired trigger occurs before "unused" stages 2 and 3 are armed.

Stage Level Pattern Capture?
1 0 0 No
2 1 1 Yes
3 0 0 No
4 0 0 No
Does work, since duplicate stages 1, 3, and 4 act together as a single stage.

Stage Level Pattern Capture?
1 0 0 No
2 1 1 Yes
3 1 1 No
4 0 0 No
Does work, since duplicate stages 1 and 4 act together as a single stage, and stages 2 and 3 act together with stage 2's "yes"-capture overriding stage 3's "no"-capture.

Stage Level Pattern Capture?
1 0 0 No
2 1 1 Yes
3 0 X No
4 0 X No
Does not work, since "unused" stages 2 and 3 bump level too soon, overriding stage 1. The trigger is effectively "match level 1".

Stage Level Pattern Capture?
1 0 0 No
2 1 0 No
3 2 1 Yes
4 2 X No
Does work.

After some reflection, I guess I blindly jumped into this topic in which to post these functional details because your spec has me thinking what a great single-point source it is to put it all. Maybe the Wiki where ian duplicated your spec is more appropriate, and maybe I could contribute there instead of dropping little crumbs here... Thanks for having taking on here the deails that are SUMP-common, especially since I understand that your main goal was to do the HP16550.
Walt.
flubberlab
Jr. Member
Jr. Member
 
Posts: 50
Joined: Sun Jan 30, 2011 5:44 am
Location: Seattle, WA

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby dogsbody » Thu May 12, 2011 4:04 am

Nice. Glad it worked!

Regarding the spec, I'd also like to have a single-point source (as you say). Originally the spec just covered the advanced trigger, but I quickly realized a more complete fpga spec would be better.

I also wanted to make it approachable. Hopefully to interest more people in fpga's if possible. Thus the background sections, drawings, etc... and my dilemma between gory detail & glazed-over eyeballs. :-)

Please feel free to post here (and/or in the wiki as you like) with any comments/nuggets of info!

I'm definitely leaning towards pushing details into an Appendix though. A programming section covering trigger setup, buffer thresholds, parsing returned buffer data, etc...
-- IED
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby flubberlab » Thu May 12, 2011 6:50 am

I think the modular format is a good idea also (same as code and hardware). AsI think you mentioned before, the documentation can seem more involved than the implementation--a design in its own right.
flubberlab
Jr. Member
Jr. Member
 
Posts: 50
Joined: Sun Jan 30, 2011 5:44 am
Location: Seattle, WA

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby hlipka » Thu May 26, 2011 2:43 pm

flubberlab wrote:I guess the desired content depends on who the spec is written for. I have considered it first and foremost as an interface spec that targets software developers that need to know precisely what the OLS can do and how to make it do it.


I recently used a SUMP client to drive a project I build (sorry, as a new user I'm not allowed to post a link here - you can only google for "a combination of 2-channel oscilloscope" :-) - it was just easier than writing my own client. I found the existing protocol documentation sparse, and in may places unclear and vague. I just had a quick glance at this document, and yet I know that it would have saved me several hours of trial and error... I really understood how the original OLS works (and I'm sure I will understand how the new core works).

Thanks for this great work!
hlipka
Jr. Member
Jr. Member
 
Posts: 71
Joined: Thu May 26, 2011 1:34 pm

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby ian » Fri May 27, 2011 1:24 am

Sorry about the spam filter. You project sounds interesting. I googled it, but no luck finding it.
User avatar
ian
Crew
Crew
 
Posts: 10803
Joined: Mon Jul 06, 2009 6:14 am

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby hlipka » Sat May 28, 2011 1:46 pm

MickM wrote:Hi;
is this it?

Yes :) But the referenced project is not the final one - this can be found here: here. It contains some bug fixes, several enhancements (e.g. being able to run standalone) and a little bit more documentation.
hlipka
Jr. Member
Jr. Member
 
Posts: 71
Joined: Thu May 26, 2011 1:34 pm

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby chautygorcy » Thu Apr 26, 2012 1:42 am

I'll take a look at the options in the source and see if I can outline the spec on the protocol wiki page. I've been meaning to make our own version with the other SUMP commands too.
chautygorcy
Newbie
Newbie
 
Posts: 2
Joined: Thu Apr 26, 2012 12:49 am

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby mrflibble » Sat Jul 21, 2012 9:11 am

Are the extra triggering features supported in the current client software?

Reason I ask is I'd like to run it on a nexys2 board, add a few features, and then make sure it'll also run on OLS hardware selectable by synthesis parameter. But for usage of demon core to make sense (over the older SUMP) the extra triggers actually being configurable from the client would be a big plus. ;) Well, aside from my personal preference of using verilog over vhdl.
User avatar
mrflibble
Newbie
Newbie
 
Posts: 7
Joined: Sat Jul 21, 2012 8:26 am

Re: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Ti

Postby dogsbody » Sun Jul 22, 2012 9:24 pm

Not that I'm aware of. Been over a year now with no sign so I'm not hopeful anymore.
-- IED
User avatar
dogsbody
Full Member
Full Member
 
Posts: 181
Joined: Wed Jan 05, 2011 3:17 am
Location: San Jose, California

PreviousNext

Return to Open Bench Logic Sniffer