Skip to main content
Topic: FPGA Verilog "Demon Core" + AdvTrigger + Meta + RLE + Timing (Read 161108 times) previous topic - next topic

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

Reply #90
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
-- debugging hardware at 2am is a bad idea...

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

Reply #91
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."

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

Reply #92
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
-- debugging hardware at 2am is a bad idea...

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

Reply #93
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.

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

Reply #94
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.

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

Reply #95
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
-- debugging hardware at 2am is a bad idea...

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

Reply #96
@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.

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

Reply #97
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
-- debugging hardware at 2am is a bad idea...

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

Reply #98
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.

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

Reply #99
[quote author="flubberlab"]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.[/quote]

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!

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

Reply #100
Sorry about the spam filter. You project sounds interesting. I googled it, but no luck finding it.
Got a question? Please ask in the forum for the fastest answers.

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

Reply #101
[quote author="MickM"]Hi;
is this it?
[/quote]
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.

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

Reply #102
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.

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

Reply #103
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.

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

Reply #104
Not that I'm aware of.  Been over a year now with no sign so I'm not hopeful anymore. 
-- IED
-- debugging hardware at 2am is a bad idea...