Merging trigger downsampler and capture system

@emard we have to merge those systems ....I think they are finished for now ... Tell me when you think I can pull a request from work repository.
I wrote a wiki about the new behavior here https://github.com/hdl4fpga/hdl4fpga/wiki/About-Trigger,-Down-sampling-and-Capture-system it is
regards

I will pull the latest stuff, hope it will at least compile :)
On 7/28/19, Miguel Angel<EMAIL_ADDRESS>wrote:

@emard we have to merge those systems ....I think they are finish ... Tell
me when you think I can pull a request from work repository.
I wrote s wiki about the new behavior here
https://github.com/hdl4fpga/hdl4fpga/wiki/About-Trigger,-Down-sampling-and-Capture-system
regards
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165

I have usbmouse update ready it works much better!
SIE module is in verilog from opencores.
I Deleted old unreliable usbmouse code.
On 7/29/19, D EMARD<EMAIL_ADDRESS>wrote:

I will pull the latest stuff, hope it will at least compile :)
On 7/28/19, Miguel Angel<EMAIL_ADDRESS>wrote:

@emard we have to merge those systems ....I think they are finish ...
Tell
me when you think I can pull a request from work repository.
I wrote s wiki about the new behavior here
https://github.com/hdl4fpga/hdl4fpga/wiki/About-Trigger,-Down-sampling-and-Capture-system
regards
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165

Tomorrow I can pull work and try (gone sleeping now :)
On 7/29/19, D EMARD<EMAIL_ADDRESS>wrote:

I have usbmouse update ready it works much better!
SIE module is in verilog from opencores.
I Deleted old unreliable usbmouse code.
On 7/29/19, D EMARD<EMAIL_ADDRESS>wrote:

I will pull the latest stuff, hope it will at least compile :)
On 7/28/19, Miguel Angel<EMAIL_ADDRESS>wrote:

@emard we have to merge those systems ....I think they are finish ...
Tell
me when you think I can pull a request from work repository.
I wrote s wiki about the new behavior here
https://github.com/hdl4fpga/hdl4fpga/wiki/About-Trigger,-Down-sampling-and-Capture-system
regards
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165

HI
I can't compile work branch (unmerged)
@E: CD145 :"/tmp/hdl4fpga/library/common/align.vhd":39:2:39:3|Formal, "di", and actual agree on type but not on size
@E: CD145 :"/tmp/hdl4fpga/library/scope/scopeio.vhd":321:22:321:35|Formal, "di", and actual agree on type but not on size
@E: CD145 :"/tmp/hdl4fpga/library/common/align.vhd":40:2:40:3|Formal, "do", and actual agree on type but not on size
@E: CD145 :"/tmp/hdl4fpga/library/scope/scopeio.vhd":321:22:321:35|Formal, "do", and actual agree on type but not on size

I've created a new branch ... I called it merge. I've left only the new system ... It seemed to compile ... Can you tried it and tell me if it works ? so then the functionality of the older one can be added

HI
Yes it compiles, and everything works, I have tested
it with oled and usb mouse, gui and video works.
in some h-zoom mode, new trace rendering system
seems to render traces differently, I "think" I have even
seen some trace rendering bug, but it's early to say is
it really so
Trigger is useable but it could be better :)
On 7/29/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I've created a new branch ... I called it merge. I've left only the new
system ... It seemed to compile ... Can you tried it and tell me if it works
? so then the functionality of the older one can be added
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-515992815

ok ... ill merge to master and will be polishing bugs
thanks
On Mon, Jul 29, 2019, 12:38 emard<EMAIL_ADDRESS>wrote:

HI
Yes it compiles, and everything works, I have tested
it with oled and usb mouse, gui and video works.
in some h-zoom mode, new trace rendering system
seems to render traces differently, I "think" I have even
seen some trace rendering bug, but it's early to say is
it really so
Trigger is useable but it could be better :)
On 7/29/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I've created a new branch ... I called it merge. I've left only the
new
system ... It seemed to compile ... Can you tried it and tell me if it
works
? so then the functionality of the older one can be added
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-515992815

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMONKQ4OWBUBK2FWE47LQB4FHNA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3BDMQI#issuecomment-516044353,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMOMKNUQRGOVEMFJM2ADQB4FHNANCNFSM4IHNIA2A
.

Let it go, if I see the bugs again, I'll report!
On 7/29/19, Miguel Angel<EMAIL_ADDRESS>wrote:

ok ... ill merge to master and will be polishing bugs

thanks

On Mon, Jul 29, 2019, 12:38 emard<EMAIL_ADDRESS>wrote:

HI

Yes it compiles, and everything works, I have tested

it with oled and usb mouse, gui and video works.

in some h-zoom mode, new trace rendering system

seems to render traces differently, I "think" I have even

seen some trace rendering bug, but it's early to say is

it really so

Trigger is useable but it could be better :)

On 7/29/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I've created a new branch ... I called it merge. I've left only
the

new

system ... It seemed to compile ... Can you tried it and tell me if it

works

? so then the functionality of the older one can be added

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-515992815

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMONKQ4OWBUBK2FWE47LQB4FHNA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3BDMQI#issuecomment-516044353,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ACYCMOMKNUQRGOVEMFJM2ADQB4FHNANCNFSM4IHNIA2A

.

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-516058911

done!

bug: At 800x480 video, traces are drawn over hzscale, vtscale and textbox

Besides that my monitor cannot deal well with the sync trimmings https://github.com/hdl4fpga/hdl4fpga/blob/master/doc/issues/images/480p.jpg. I cannot make it do it wrong.
Those are the modes https://github.com/hdl4fpga/hdl4fpga/blob/f8deef12fe0ee1a9dca8d8b680fc95874a49d29f/library/scope/scopeiopkg.vhd#L145 and https://github.com/hdl4fpga/hdl4fpga/blob/f8deef12fe0ee1a9dca8d8b680fc95874a49d29f/library/scope/scopeiopkg.vhd#L241 , aren't they ?
Here is my test https://github.com/hdl4fpga/hdl4fpga/blob/2b74737ef164f6e868c4c397f3301c1d65e112b1/s3starter/scopeio/scopeio.vhd#L119. Have I done something wrong ? Xtal is 50 Mhz divided by 5 a multiplied by 3, 30 Mhz is gotten. But sync seems fine.

hmm I away now and here I have only this small screen
800x480 with me (30 MHz pixel clock)
I see the similar traces issue at OLED 96x64 maybe that could
you try?
On 7/30/19, Miguel Angel<EMAIL_ADDRESS>wrote:

Besides that my monitor cannot deal well with the sync trimmings
https://github.com/hdl4fpga/hdl4fpga/blob/master/doc/issues/images/480p.jpg.
I cannot make it do it wrong.
Those are the modes
https://github.com/hdl4fpga/hdl4fpga/blob/f8deef12fe0ee1a9dca8d8b680fc95874a49d29f/library/scope/scopeiopkg.vhd#L145
and
https://github.com/hdl4fpga/hdl4fpga/blob/f8deef12fe0ee1a9dca8d8b680fc95874a49d29f/library/scope/scopeiopkg.vhd#L241
, aren't they ?
Here is my test
https://github.com/hdl4fpga/hdl4fpga/blob/2b74737ef164f6e868c4c397f3301c1d65e112b1/s3starter/scopeio/scopeio.vhd#L119.
Have I done something wrong ? Xtal is 50 Mhz divided by 5 a multiplied by 3,
30 Mhz is gotten. But sync seems fine.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-516477927

I can't test it again but when I was last trying modes
even without much timing tweaking, my lenovo monitor
accepted 800x480 60Hz 30MHz
On 7/30/19, D EMARD<EMAIL_ADDRESS>wrote:

hmm I away now and here I have only this small screen
800x480 with me (30 MHz pixel clock)
I see the similar traces issue at OLED 96x64 maybe that could
you try?
On 7/30/19, Miguel Angel<EMAIL_ADDRESS>wrote:

Besides that my monitor cannot deal well with the sync trimmings
https://github.com/hdl4fpga/hdl4fpga/blob/master/doc/issues/images/480p.jpg.
I cannot make it do it wrong.
Those are the modes
https://github.com/hdl4fpga/hdl4fpga/blob/f8deef12fe0ee1a9dca8d8b680fc95874a49d29f/library/scope/scopeiopkg.vhd#L145
and
https://github.com/hdl4fpga/hdl4fpga/blob/f8deef12fe0ee1a9dca8d8b680fc95874a49d29f/library/scope/scopeiopkg.vhd#L241
, aren't they ?
Here is my test
https://github.com/hdl4fpga/hdl4fpga/blob/2b74737ef164f6e868c4c397f3301c1d65e112b1/s3starter/scopeio/scopeio.vhd#L119.
Have I done something wrong ? Xtal is 50 Mhz divided by 5 a multiplied by
3,
30 Mhz is gotten. But sync seems fine.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-516477927

I got this using 800x600 sync timmings:

96x64

https://raw.githubusercontent.com/hdl4fpga/hdl4fpga/master/doc/issues/images/96x64at800x600.jpg

800x480p

https://raw.githubusercontent.com/hdl4fpga/hdl4fpga/master/doc/issues/images/480pat800x600.jpg

HI
Hm on 96x64 I think I see trace going over vtscale
on 800x480 not sure.
Can I recommend to post large images to another git repository
hdl4fpga one is rapidly growing over 100 MB, I need
few backup copies and I'm slowly going out of disk space :)
Maybe not immediately, but in some future, a git cleanup purge
should be done to remove accumulated binaries...
On 7/30/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I got this using 800x600 sync timmings:

96x64

https://raw.githubusercontent.com/hdl4fpga/hdl4fpga/master/doc/issues/images/96x64at800x600.jpg

800x480p

https://raw.githubusercontent.com/hdl4fpga/hdl4fpga/master/doc/issues/images/480pat800x600.jpg
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-516509048

I had that behavior before I merged the new down sampling system. I've compared to master again and everything seems to be fine.
I cannot understand.
I will move the images.

On that 96x64, the scale is inside the grid  and that is why traces are there.

reoving images are not enough to clalim space as git will
remeber them still  and just double the space using diff again
for removal)
a rebase with hard cleanup is needed (backup everything 2 times
before trying this)
https://help.github.com/en/articles/removing-sensitive-data-from-a-repository
On 7/30/19, Miguel Angel<EMAIL_ADDRESS>wrote:

On that 96x64, the scale is inside the grid  and that is why traces are
there.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-516512597

thanks

To easier reproduce the bug I made 640x480 mode
which should be standard for any monitor 25 MHz pixel clock
I didn't make the timing as I don't have monitor here
but I guess you can load it to any higher mode to see the
traces bug.
On 7/30/19, Miguel Angel<EMAIL_ADDRESS>wrote:

thanks
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-516516711

HI
I'm trying to reconstruct special case when downsampling = '0'
can/are the data be so structured that without knowing the number
of input channels I can handle this special case e.g. with something
like this
    captured_data <= rd_data_ds when downsampling = '1'
                else rd_data_ds(0 to rd_data_ds'length/2-1)
                   & rd_data_ds(0 to rd_data_ds'length/2-1)
                     when rd_addr(rd_addr'high) = '0'
                else rd_data_ds(rd_data_ds'length/2 to rd_data_ds'high)
                   & rd_data_ds(rd_data_ds'length/2 to rd_data_ds'high);

On 7/30/19, D EMARD<EMAIL_ADDRESS>wrote:

To easier reproduce the bug I made 640x480 mode
which should be standard for any monitor 25 MHz pixel clock
I didn't make the timing as I don't have monitor here
but I guess you can load it to any higher mode to see the
traces bug.
On 7/30/19, Miguel Angel<EMAIL_ADDRESS>wrote:

thanks
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-516516711

If I understood well, Have you taken into account that rd_addr should be delay 2 cylcles because of data delay ? That is the only thing I can think of now.
The other things seem to be right.

Yep ... I've found something ... I'm working on it.
On Tue, Jul 30, 2019 at 4:27 PM emard<EMAIL_ADDRESS>wrote:

To easier reproduce the bug I made 640x480 mode
which should be standard for any monitor 25 MHz pixel clock
I didn't make the timing as I don't have monitor here
but I guess you can load it to any higher mode to see the
traces bug.
On 7/30/19, Miguel Angel<EMAIL_ADDRESS>wrote:

thanks
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-516516711

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOI7ABDZKBUQ363QYELQCCIZ3A5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3FBFDI#issuecomment-516559501,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMOJJELCRIVJLQV36X4TQCCIZ3ANCNFSM4IHNIA2A
.

Sorry ... It was the monitor not synchronizing correctly. ... Everything seems to be fine
https://github.com/hdl4fpga/hdl4fpga.github.io/raw/master/images/hdl4fpga/issues/vesa640x480.jpg
Those are Xilinx ISE ... I'll check on ecp3versa

Definitely a Diamond Lattice bug ... it started to trash ... I'll go on tomorrow

aiieee diamond bugs again :(
well I'm glad that you can reproduce this!
I nearly wanted to discard 2x buffer but I supported it with some
bit shuffling... BRAM is small and it's good to have larger buffer sometimes :)
yeah delay, there is some minor bug with align to grid 1-2 pixels off depending
on downsampling=0/1, I can fix that later, it's easy
I have another bug at "click to trigger", I wonder how a simple GUI function
can hold so much bugs :(
On 7/31/19, Miguel Angel<EMAIL_ADDRESS>wrote:

Definitely a Diamond Lattice bug ... it started to trash ... I'll go on
tomorrow
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-516658232

I think I found the bug
https://github.com/hdl4fpga/hdl4fpga/blob/dfbfb3723124eda38b16a23c8c7a7265238d8d28/library/common/rom.vhd#L63. Xilinx wants it to be signal or crash, Lattice Diamond wants it to be constant or generates garbage. I set it constant to try.
This is ScopeIO running at 640x480 on ecp3versa https://github.com/hdl4fpga/hdl4fpga.github.io/raw/master/images/hdl4fpga/issues/ecp3versa640x480vesa.jpg
It seems everything to be right.

HI
I pulled the git but the bug is still the same
traces look similar to
hzaxis_height = vtaxis_width = 0
but the actual values are 8 and 6*8 :)
So actually traces should be hidden there but they are drawn
when we are at value 0, the hzscale is placed
on top of the grid - I can support that on the GUI
if neccessary but if it's not a big deal I'd like
if you can place hzaxis below the grid
on the same position when hzaxis_height = 0
as with hzaxis_height = 8
On 7/31/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I think I found the bug
https://github.com/hdl4fpga/hdl4fpga/blob/dfbfb3723124eda38b16a23c8c7a7265238d8d28/library/common/rom.vhd#L63.
Xilinx wants it to be signal or crash, Lattice Diamond wants it to be
constant or generates garbage. I set it constant to try.
This is ScopeIO running at 640x480 on ecp3versa
https://github.com/hdl4fpga/hdl4fpga.github.io/raw/master/images/hdl4fpga/issues/ecp3versa640x480vesa.jpg
It seems everything to be right.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-516907570

On Wed, Jul 31, 2019 at 3:28 PM emard<EMAIL_ADDRESS>wrote:

HI
I pulled the git but the bug is still the same
traces look similar to
hzaxis_height = vtaxis_width = 0
but the actual values are 8 and 6*8 :)
So actually traces should be hidden there but they are drawn
😣  ... something is still broken ... I'll try to figure it out.

when we are at value 0, the hzscale is placed
on top of the grid - I can support that on the GUI
if neccessary but if it's not a big deal I'd like
if you can place hzaxis below the grid
on the same position when hzaxis_height = 0
as with hzaxis_height = 8

I'll try to do that after finding the bug. hzaxis is on top because it is
easier to compare to 0, but the cost to compare to anything else should be
the same.

On 7/31/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I think I found the bug

https://github.com/hdl4fpga/hdl4fpga/blob/dfbfb3723124eda38b16a23c8c7a7265238d8d28/library/common/rom.vhd#L63
.

Xilinx wants it to be signal or crash, Lattice Diamond wants it to be
constant or generates garbage. I set it constant to try.
This is ScopeIO running at 640x480 on ecp3versa

https://github.com/hdl4fpga/hdl4fpga.github.io/raw/master/images/hdl4fpga/issues/ecp3versa640x480vesa.jpg

It seems everything to be right.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-516907570

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOOBCGONQ4BXXKPHXU3QCHKUTA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3IEQBI#issuecomment-516966405,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMOKEPWQFO77E7MLZ6KDQCHKUTANCNFSM4IHNIA2A
.

I couldn't find the bug that you told me ... but I found several weird thing tool bugs. I'am currently using Lattice Diamond <IP_ADDRESS> on ecp3versa. The bug I'm going to describe made bitstream not generating even the sync timings :
if I instanced scopeio with
generic map (vlayout_id => 0)
it works perfectly but if I declared a
constant layoutid : natural := 0;
and then used it
generic map (vlayout_id => layouyid)
I got a complete black screen
So, I think scopeio is making the tool get its limits. I think there is a buffer overflow or stack overflow somewhere on Lattice Diamond.

your vhdl writing style is advanced, tools are surprized and unready :-)
I'm using diamond 3.7 and this is the last known to me
that synthesizes f32c up to 100 MHz
yes I also think there is a lot of memory leak and bad pointers in diamond.
from time to time, it leads to segmentation fault, for example
this completely crashed the diamond I made a typo:
if R_rx_done <= '1' then
a hard crash without even a line number where it happend,
I fixed it with
if R_rx_done = '1' then
compiled ok
You have ulx3s now so you can also try ecp5 maybe you find some
clue
On 8/1/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I couldn't find the bug that you told me ... but I found several weird thing
tool bugs. I'am currently using Lattice Diamond <IP_ADDRESS> on ecp3versa. The
bug I'm going to describe made bitstream not generating even the sync
timings :
if I instanced scopeio with
generic map (vlayout_id => 0)
it works perfectly but if I declared a
constant layoutid : natural := 0;
and then used it
generic map (vlayout_id => layouyid)
I got a complete black screen
So, I think scopeio is making the tool get its limits. I think there is
a buffer overflow or stack overflow somewhere on Lattice Diamond.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517384391

Apart from that I'd suggest to also port to some altera cyclone4 or
whatever you have handy. every one of them Xilinx,Altera,Lattice will
dump errors at different parts of the code. In my experience, 2 of them
are not enough to tell is the code wrong or the compiler
On 8/1/19, D EMARD<EMAIL_ADDRESS>wrote:

your vhdl writing style is advanced, tools are surprized and unready :-)
I'm using diamond 3.7 and this is the last known to me
that synthesizes f32c up to 100 MHz
yes I also think there is a lot of memory leak and bad pointers in diamond.
from time to time, it leads to segmentation fault, for example
this completely crashed the diamond I made a typo:
if R_rx_done <= '1' then
a hard crash without even a line number where it happend,
I fixed it with
if R_rx_done = '1' then
compiled ok
You have ulx3s now so you can also try ecp5 maybe you find some
clue
On 8/1/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I couldn't find the bug that you told me ... but I found several weird
thing
tool bugs. I'am currently using Lattice Diamond <IP_ADDRESS> on ecp3versa.
The
bug I'm going to describe made bitstream not generating even the sync
timings :
if I instanced scopeio with
generic map (vlayout_id => 0)
it works perfectly but if I declared a
constant layoutid : natural := 0;
and then used it
generic map (vlayout_id => layouyid)
I got a complete black screen
So, I think scopeio is making the tool get its limits. I think there
is
a buffer overflow or stack overflow somewhere on Lattice Diamond.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517384391

I have to try on it ... that's the next thing
On Thu, Aug 1, 2019 at 2:43 PM emard<EMAIL_ADDRESS>wrote:

your vhdl writing style is advanced, tools are surprized and unready :-)
I'm using diamond 3.7 and this is the last known to me
that synthesizes f32c up to 100 MHz
yes I also think there is a lot of memory leak and bad pointers in diamond.
from time to time, it leads to segmentation fault, for example
this completely crashed the diamond I made a typo:
if R_rx_done <= '1' then
a hard crash without even a line number where it happend,
I fixed it with
if R_rx_done = '1' then
compiled ok
You have ulx3s now so you can also try ecp5 maybe you find some
clue
On 8/1/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I couldn't find the bug that you told me ... but I found several weird
thing
tool bugs. I'am currently using Lattice Diamond <IP_ADDRESS> on ecp3versa.
The
bug I'm going to describe made bitstream not generating even the sync
timings :
if I instanced scopeio with
generic map (vlayout_id => 0)
it works perfectly but if I declared a
constant layoutid : natural := 0;
and then used it
generic map (vlayout_id => layouyid)
I got a complete black screen
So, I think scopeio is making the tool get its limits. I think there
is
a buffer overflow or stack overflow somewhere on Lattice Diamond.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517384391

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOJPLV2J2BVR3KEKUKTQCMOELA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3LLVHA#issuecomment-517388956,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMOMBYFX6GP2AOJG7GSTQCMOELANCNFSM4IHNIA2A
.

here are some binaries to get started
also the scopeio bitstreams are there so you can try
https://github.com/emard/ulx3s-bin
On 8/1/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I have to try on it ... that's the next thing

On Thu, Aug 1, 2019 at 2:43 PM emard<EMAIL_ADDRESS>wrote:

your vhdl writing style is advanced, tools are surprized and unready :-)

I'm using diamond 3.7 and this is the last known to me

that synthesizes f32c up to 100 MHz

yes I also think there is a lot of memory leak and bad pointers in
diamond.

from time to time, it leads to segmentation fault, for example

this completely crashed the diamond I made a typo:

if R_rx_done <= '1' then

a hard crash without even a line number where it happend,

I fixed it with

if R_rx_done = '1' then

compiled ok

You have ulx3s now so you can also try ecp5 maybe you find some

clue

On 8/1/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I couldn't find the bug that you told me ... but I found several weird

thing

tool bugs. I'am currently using Lattice Diamond <IP_ADDRESS> on
ecp3versa.

The

bug I'm going to describe made bitstream not generating even the sync

timings :

if I instanced scopeio with

generic map (vlayout_id => 0)

it works perfectly but if I declared a

constant layoutid : natural := 0;

and then used it

generic map (vlayout_id => layouyid)

I got a complete black screen

So, I think scopeio is making the tool get its limits. I think
there

is

a buffer overflow or stack overflow somewhere on Lattice Diamond.

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517384391

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOJPLV2J2BVR3KEKUKTQCMOELA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3LLVHA#issuecomment-517388956,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ACYCMOMBYFX6GP2AOJG7GSTQCMOELANCNFSM4IHNIA2A

.

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517391092

True
On Thu, Aug 1, 2019 at 2:49 PM emard<EMAIL_ADDRESS>wrote:

Apart from that I'd suggest to also port to some altera cyclone4 or
whatever you have handy. every one of them Xilinx,Altera,Lattice will
dump errors at different parts of the code. In my experience, 2 of them
are not enough to tell is the code wrong or the compiler
On 8/1/19, D EMARD<EMAIL_ADDRESS>wrote:

your vhdl writing style is advanced, tools are surprized and unready :-)
I'm using diamond 3.7 and this is the last known to me
that synthesizes f32c up to 100 MHz
yes I also think there is a lot of memory leak and bad pointers in
diamond.
from time to time, it leads to segmentation fault, for example
this completely crashed the diamond I made a typo:
if R_rx_done <= '1' then
a hard crash without even a line number where it happend,
I fixed it with
if R_rx_done = '1' then
compiled ok
You have ulx3s now so you can also try ecp5 maybe you find some
clue
On 8/1/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I couldn't find the bug that you told me ... but I found several weird
thing
tool bugs. I'am currently using Lattice Diamond <IP_ADDRESS> on ecp3versa.
The
bug I'm going to describe made bitstream not generating even the sync
timings :
if I instanced scopeio with
generic map (vlayout_id => 0)
it works perfectly but if I declared a
constant layoutid : natural := 0;
and then used it
generic map (vlayout_id => layouyid)
I got a complete black screen
So, I think scopeio is making the tool get its limits. I think there
is
a buffer overflow or stack overflow somewhere on Lattice Diamond.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517384391

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOK7OODQG7QWFQDQC6DQCMO2FA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3LMFEA#issuecomment-517390992,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMONAKPPH72MCY5BGBE3QCMO2FANCNFSM4IHNIA2A
.

Thanks
On Thu, Aug 1, 2019 at 2:50 PM emard<EMAIL_ADDRESS>wrote:

here are some binaries to get started
also the scopeio bitstreams are there so you can try
https://github.com/emard/ulx3s-bin
On 8/1/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I have to try on it ... that's the next thing

On Thu, Aug 1, 2019 at 2:43 PM emard<EMAIL_ADDRESS>wrote:

your vhdl writing style is advanced, tools are surprized and unready :-)

I'm using diamond 3.7 and this is the last known to me

that synthesizes f32c up to 100 MHz

yes I also think there is a lot of memory leak and bad pointers in
diamond.

from time to time, it leads to segmentation fault, for example

this completely crashed the diamond I made a typo:

if R_rx_done <= '1' then

a hard crash without even a line number where it happend,

I fixed it with

if R_rx_done = '1' then

compiled ok

You have ulx3s now so you can also try ecp5 maybe you find some

clue

On 8/1/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I couldn't find the bug that you told me ... but I found several weird

thing

tool bugs. I'am currently using Lattice Diamond <IP_ADDRESS> on
ecp3versa.

The

bug I'm going to describe made bitstream not generating even the sync

timings :

if I instanced scopeio with

generic map (vlayout_id => 0)

it works perfectly but if I declared a

constant layoutid : natural := 0;

and then used it

generic map (vlayout_id => layouyid)

I got a complete black screen

So, I think scopeio is making the tool get its limits. I think
there

is

a buffer overflow or stack overflow somewhere on Lattice Diamond.

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517384391

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

<
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOJPLV2J2BVR3KEKUKTQCMOELA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3LLVHA#issuecomment-517388956
,

or mute the thread

<
https://github.com/notifications/unsubscribe-auth/ACYCMOMBYFX6GP2AOJG7GSTQCMOELANCNFSM4IHNIA2A

.

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517391092

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMONAD7IMFEHZPXIYDZDQCMPABA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3LMJ3Q#issuecomment-517391598,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMOIVRIQXG5BWQCDFJRDQCMPABANCNFSM4IHNIA2A
.

I compiled https://github.com/hdl4fpga/hdl4fpga/blob/master/ULX3S/diamond/ulx3s_12f_scope.ldf ti check the bug and got this error.
52111106	ERROR - EHXPLLL 'clk_25M/clk_video_cpu_v_inst/pll_i' output CLKOP with -90 degree phase shift should not be used as the feedback signal (FEEDBK_PATH = INT_OP).

Let me see and fix
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I compiled
https://github.com/hdl4fpga/hdl4fpga/blob/master/ULX3S/diamond/ulx3s_12f_scope.ldf
ti check the bug and got this error.
52111106	ERROR - EHXPLLL 'clk_25M/clk_video_cpu_v_inst/pll_i' output CLKOP
with -90 degree phase shift should not be used as the feedback signal
(FEEDBK_PATH = INT_OP).
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517800090

I generated this clock with my diamond 3.7
If it's still uncompileable, you may need to generate such clock with
your local diamond version....
On 8/2/19, D EMARD<EMAIL_ADDRESS>wrote:

Let me see and fix
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

I compiled
https://github.com/hdl4fpga/hdl4fpga/blob/master/ULX3S/diamond/ulx3s_12f_scope.ldf
ti check the bug and got this error.
52111106	ERROR - EHXPLLL 'clk_25M/clk_video_cpu_v_inst/pll_i' output
CLKOP
with -90 degree phase shift should not be used as the feedback signal
(FEEDBK_PATH = INT_OP).
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517800090

It compiled

I'm here to help
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

It compiled
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517813240

It compiled and programmed ... ;) I'm sending you a picture in the next one
On Fri, Aug 2, 2019 at 4:12 PM emard<EMAIL_ADDRESS>wrote:

I'm here to help
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

It compiled
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517813240

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOKCJIINVVI4QPUL7ZTQCSBIJA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3OTLOA#issuecomment-517813688,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMOKZZIGXJ3HG7AMYD5TQCSBIJANCNFSM4IHNIA2A
.

wow
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

It compiled and programmed ... ;) I'm sending you a picture in the next
one

On Fri, Aug 2, 2019 at 4:12 PM emard<EMAIL_ADDRESS>wrote:

I'm here to help

On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

It compiled

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517813240

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOKCJIINVVI4QPUL7ZTQCSBIJA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3OTLOA#issuecomment-517813688,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ACYCMOKZZIGXJ3HG7AMYD5TQCSBIJANCNFSM4IHNIA2A

.

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517815904

Is this the bug ? https://github.com/hdl4fpga/hdl4fpga.github.io/raw/master/images/hdl4fpga/issues/mybebug.jpg

There is white line around

no but bug looks very similar to this,
you have to set
hzaxis_height = 8, vtaxis_width = 6*8
in my default source currently bug is hidden,
as I have set height = 0, vtaxis_width = 0
to see the bug, instead of
lcd800x480ongrid
you have to use
lcd800x480
however visually it will not look too much different anyway :)
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

There is white line around
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517821346

Now I see it

if you set trig1shot to false, is the bug still there ?

yes
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

if you set trig1shot to false, is the bug still there ?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517827042

This what I get when I set trig1shot to false, and  constant vlayout_id: integer := 8; that is lcd800x480 ... I've  only change those constant.https://github.com/hdl4fpga/hdl4fpga.github.io/blob/master/images/hdl4fpga/issues/layout%3D8.jpg. Yellow line is limited to the grid.

hmmmmmmmm let me try this
in this case trig1shot should be responsible :(
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

This is what I get when I set trig1shot to false, and  constant
vlayout_id: integer := 8; that is lcd800x480 ... I've  only change
those
constant.https://github.com/hdl4fpga/hdl4fpga.github.io/blob/master/images/hdl4fpga/issues/layout%3D8.jpg.
Yellow line is limited to the grid.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517834267

Yes with trig1shot disabled, traces are indeed limited to the
grid. Now I wonder what do I have missing in trig1shot
and what your trigger has to make it work correctlyy
On 8/2/19, D EMARD<EMAIL_ADDRESS>wrote:

hmmmmmmmm let me try this
in this case trig1shot should be responsible :(
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

This is what I get when I set trig1shot to false, and  constant
vlayout_id: integer := 8; that is lcd800x480 ... I've  only change
those
constant.https://github.com/hdl4fpga/hdl4fpga.github.io/blob/master/images/hdl4fpga/issues/layout%3D8.jpg.
Yellow line is limited to the grid.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517834267

there is this signal capture_av which I don't understand
what data should I output if its 0 or 1
On 8/2/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes with trig1shot disabled, traces are indeed limited to the
grid. Now I wonder what do I have missing in trig1shot
and what your trigger has to make it work correctlyy
On 8/2/19, D EMARD<EMAIL_ADDRESS>wrote:

hmmmmmmmm let me try this
in this case trig1shot should be responsible :(
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

This is what I get when I set trig1shot to false, and  constant
vlayout_id: integer := 8; that is lcd800x480 ... I've  only change
those
constant.https://github.com/hdl4fpga/hdl4fpga.github.io/blob/master/images/hdl4fpga/issues/layout%3D8.jpg.
Yellow line is limited to the grid.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517834267

I think I understand, this is trace enabler from video system
I need to somehow construct "invisible" data :)
On 8/2/19, D EMARD<EMAIL_ADDRESS>wrote:

there is this signal capture_av which I don't understand
what data should I output if its 0 or 1
On 8/2/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes with trig1shot disabled, traces are indeed limited to the
grid. Now I wonder what do I have missing in trig1shot
and what your trigger has to make it work correctlyy
On 8/2/19, D EMARD<EMAIL_ADDRESS>wrote:

hmmmmmmmm let me try this
in this case trig1shot should be responsible :(
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

This is what I get when I set trig1shot to false, and  constant
vlayout_id: integer := 8; that is lcd800x480 ... I've  only
change
those
constant.https://github.com/hdl4fpga/hdl4fpga.github.io/blob/master/images/hdl4fpga/issues/layout%3D8.jpg.
Yellow line is limited to the grid.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517834267

can I have small help?
if I want to generate off-screen sample value for trace to be invisible
when capture_av=0, do I have some constant in some package
which in sample date makes this sample invisible?
On 8/2/19, D EMARD<EMAIL_ADDRESS>wrote:

I think I understand, this is trace enabler from video system
I need to somehow construct "invisible" data :)
On 8/2/19, D EMARD<EMAIL_ADDRESS>wrote:

there is this signal capture_av which I don't understand
what data should I output if its 0 or 1
On 8/2/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes with trig1shot disabled, traces are indeed limited to the
grid. Now I wonder what do I have missing in trig1shot
and what your trigger has to make it work correctlyy
On 8/2/19, D EMARD<EMAIL_ADDRESS>wrote:

hmmmmmmmm let me try this
in this case trig1shot should be responsible :(
On 8/2/19, Miguel Angel<EMAIL_ADDRESS>wrote:

This is what I get when I set trig1shot to false, and  constant
vlayout_id: integer := 8; that is lcd800x480 ... I've  only
change
those
constant.https://github.com/hdl4fpga/hdl4fpga.github.io/blob/master/images/hdl4fpga/issues/layout%3D8.jpg.
Yellow line is limited to the grid.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517834267

Of course ... that was I had meant with "we have to merge"

And I was waiting for you to ask me about your trigger functionality to merge both

And I'haven't realized that you had added yours again :))))))))) .... till yesterday

I overlooked the complexity and thought I will understand
everything easily just from the code,
but obviously it it's more complicated than
at the first glance, aiiieeeee :(
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

And I'haven't realized that you had added yours again :))))))))) .... till
yesterday
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517856984

First I want to make a merge of both functionalities to move on and then
I'll write a wiki to explain it ... I'll help me to understand what myself
from the past did ... :)))))))))
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon
Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Aug 2, 2019 at 7:15 PM emard<EMAIL_ADDRESS>wrote:

I overlooked the complexity and thought I will understand
everything easily just from the code,
but obviously it it's more complicated than
at the first glance, aiiieeeee :(
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

And I'haven't realized that you had added yours again :))))))))) ....
till
yesterday
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517856984

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMONTTWFNFSM5FN455TTQCSWZ5A5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3O6RDY#issuecomment-517859471,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMOKUM4ZY3R2LZTOGBNTQCSWZ5ANCNFSM4IHNIA2A
.

trig1shot itself works great, i am using it to support USB mouse
and it is able to catch all events the same as normal storage scope would
My storage module needs to generate "invisible"
samples so the traces don't appear at the hzscale I tried
few tricks but trace is always visible somewhere. I don't
understand how your "capture" module makes it invisible
out of grid.
For now, I can set all sample values to 0, this can be
a workaround.
this will mark the 0 position of each trace, so it can even have
a practical purpose, however being an ugly solution until
we have something better
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

First I want to make a merge of both functionalities to move on and then

I'll write a wiki to explain it ... I'll help me to understand what myself

from the past did ... :)))))))))

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon

Virus-free.

www.avast.com

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Aug 2, 2019 at 7:15 PM emard<EMAIL_ADDRESS>wrote:

I overlooked the complexity and thought I will understand

everything easily just from the code,

but obviously it it's more complicated than

at the first glance, aiiieeeee :(

On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

And I'haven't realized that you had added yours again :))))))))) ....

till

yesterday

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517856984

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMONTTWFNFSM5FN455TTQCSWZ5A5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3O6RDY#issuecomment-517859471,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ACYCMOKUM4ZY3R2LZTOGBNTQCSWZ5ANCNFSM4IHNIA2A

.

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517862301

dont merge this pull requesst i must clean
On 8/3/19, D EMARD<EMAIL_ADDRESS>wrote:

trig1shot itself works great, i am using it to support USB mouse
and it is able to catch all events the same as normal storage scope would
My storage module needs to generate "invisible"
samples so the traces don't appear at the hzscale I tried
few tricks but trace is always visible somewhere. I don't
understand how your "capture" module makes it invisible
out of grid.
For now, I can set all sample values to 0, this can be
a workaround.
this will mark the 0 position of each trace, so it can even have
a practical purpose, however being an ugly solution until
we have something better
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

First I want to make a merge of both functionalities to move on and then

I'll write a wiki to explain it ... I'll help me to understand what
myself

from the past did ... :)))))))))

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon

Virus-free.

www.avast.com

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Aug 2, 2019 at 7:15 PM emard<EMAIL_ADDRESS>wrote:

I overlooked the complexity and thought I will understand

everything easily just from the code,

but obviously it it's more complicated than

at the first glance, aiiieeeee :(

On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

And I'haven't realized that you had added yours again :))))))))) ....

till

yesterday

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517856984

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMONTTWFNFSM5FN455TTQCSWZ5A5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3O6RDY#issuecomment-517859471,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ACYCMOKUM4ZY3R2LZTOGBNTQCSWZ5ANCNFSM4IHNIA2A

.

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517862301

https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_capture.vhd#L45
there capture_av tells the system when the video address to plot is valid. https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_video.vhd#L69
scopeio_video set that signal.
to disable the trace, you have to set capture_dv to '0' along the sample you don't want to show.
https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_capture.vhd#L47
When you make it work we have to agree on an interface, so there is no if generate if not generate in scopeio.vhd. Modules will be selected by Configuration Declaration There are other users that want to add their trigger systems

HI
I  think I fixed it to work.
I must first understand what you mean by "interface" (is it port map namespace?)
and  "configuration declaration" (i'm not sure is it list of files to
compile or something
else in vhdl language different than if/generate?)
I only understand fully that you want if/generate to go away
1-shot structure of modules is slightly different than your trigger,
I have separate capture and storage module while I have triggering
integrated in the capture.
You have separated triggering but integrated capture and storage.
Do you want me to make trig1shot as compatible port map namespace
and a kind of a glue module that glues capture and storage?
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_capture.vhd#L45
there capture_av tells the system when the video address to plot is
valid.
https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_video.vhd#L69
scopeio_video set that signal.
to disable the trace, you have to set capture_dv to '0' along the sample
you don't want to show.
https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_capture.vhd#L47
When you make it work we have to agree on an interface, so there is no if
generate if not generate in scopeio.vhd. Modules will be selected by
Configuration Declaration There are other users that want to add their
trigger systems
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517867930

On Fri, Aug 2, 2019 at 9:19 PM emard<EMAIL_ADDRESS>wrote:

HI
I think I fixed it to work.
I must first understand what you mean by "interface" (is it port map
namespace?)

Yes  ....

and "configuration declaration" (i'm not sure is it list of files to
compile or something
else in vhdl language different than if/generate?)

It is a VHDL syntax that let you to place different entities on components
without knowing what is inside of the high level architecture
Something similar to software shared library .... you can replace a shared
library by yours without knowing what the program that uses it does
meanwhile the specification of the library is compliant
You can think of opengl in linux:  you have Mesa or manufactures owns one.
In that way, you can add all available trigger systems on the same library
or external ones and choose whatever entity you want on the component that
is used without touching or even know what scopeio is about.
Here is a much better explanation ... this is one of reasons why I love
VHDL ... that structure is part of first ever VHDL standard in 1988.
https://www.doulos.com/knowhow/vhdl_designers_guide/configurations_part_1/

I only understand fully that you want if/generate to go away

I want users, all of them, can custom as much as they want without make
scopeio a if itisme gnenerate
:)

1-shot structure of modules is slightly different than your trigger,
I have separate capture and storage module while I have triggering
integrated in the capture.
And I want it to be there ... it is you who understand how it works and
you need it

You have separated triggering but integrated capture and storage.
Do you want me to make trig1shot as compatible port map namespace
and a kind of a glue module that glues capture and storage?
What I want is to try to find a general interface ( as much as it is
possible) that lets your triggers system and mine being chosen using
component on VHDL completly transparent , no preferences. That is the
main goal of *configuration declaration *in VHDL

On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_capture.vhd#L45

there capture_av tells the system when the video address to plot is
valid.

https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_video.vhd#L69

scopeio_video set that signal.
to disable the trace, you have to set capture_dv to '0' along the
sample
you don't want to show.

https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_capture.vhd#L47

When you make it work we have to agree on an interface, so there is no
if
generate if not generate in scopeio.vhd. Modules will be selected
by
Configuration Declaration There are other users that want to add
their
trigger systems
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517867930

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOK3IG7JYLVJBTIVTRTQCTFHVA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PC7UA#issuecomment-517877712,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMOMD3FVL5IN7AMYIFVDQCTFHVANCNFSM4IHNIA2A
.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon
Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Thanks, it seems I never used configuration declaration before,
but I'm slowly starting to understand... :)
I found it is already used in s3estarter and nuhs3adsp
so I can have some code examples too
until I understand it better, I can think of it as
clean replacement for if/generate
To migrate I suggest we do it in steps.
First step - separate files to directories in classical way,
each file set has glue module that fits to the same "component"
library/scopeio/tcs
trigger_capture_storage_component.vhd -- common to both
your "default"
library/scopeio/tcs/default/
trigger_capture_storage.vhd -- glue module for your system
scopeio_tcs_default_trigger.vhd
scopeio_tcs_default_capture_storage.vhd
my "1shot"
library/scopeio/tcs/oneshot/
trigger_capture_storage.vhd -- glue module for my system
scopeio_tcs_1shot_trigger_capture.vhd
scopeio_tcs_1shot_storage.vhd
we have already scopeio_trigger.vhd, it is not a trigger
but just a level comparator so I suggest to rename it to
scopeio_level_comparator.vhd
what do you think
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

On Fri, Aug 2, 2019 at 9:19 PM emard<EMAIL_ADDRESS>wrote:

HI

I think I fixed it to work.

I must first understand what you mean by "interface" (is it port map

namespace?)

Yes  ....

and "configuration declaration" (i'm not sure is it list of files to

compile or something

else in vhdl language different than if/generate?)

It is a VHDL syntax that let you to place different entities on components

without knowing what is inside of the high level architecture

Something similar to software shared library .... you can replace a shared

library by yours without knowing what the program that uses it does

meanwhile the specification of the library is compliant

You can think of opengl in linux:  you have Mesa or manufactures owns one.

In that way, you can add all available trigger systems on the same library

or external ones and choose whatever entity you want on the component that

is used without touching or even know what scopeio is about.

Here is a much better explanation ... this is one of reasons why I love

VHDL ... that structure is part of first ever VHDL standard in 1988.

https://www.doulos.com/knowhow/vhdl_designers_guide/configurations_part_1/

I only understand fully that you want if/generate to go away

I want users, all of them, can custom as much as they want without make

scopeio a if itisme gnenerate

:)

1-shot structure of modules is slightly different than your trigger,

I have separate capture and storage module while I have triggering

integrated in the capture.

And I want it to be there ... it is you who understand how it works and

you need it

You have separated triggering but integrated capture and storage.

Do you want me to make trig1shot as compatible port map namespace

and a kind of a glue module that glues capture and storage?

What I want is to try to find a general interface ( as much as it is

possible) that lets your triggers system and mine being chosen using

component on VHDL completly transparent , no preferences. That is the

main goal of *configuration declaration *in VHDL

On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_capture.vhd#L45

there capture_av tells the system when the video address to plot
is

valid.

https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_video.vhd#L69

scopeio_video set that signal.

to disable the trace, you have to set capture_dv to '0' along the

sample

you don't want to show.

https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_capture.vhd#L47

_When you make it work we have to agree on an interface, so there is
no

**if

generate if not generate** in scopeio.vhd. Modules will be
selected

by

Configuration Declaration There are other users that want to add

their

trigger systems_

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517867930

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOK3IG7JYLVJBTIVTRTQCTFHVA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PC7UA#issuecomment-517877712,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ACYCMOMD3FVL5IN7AMYIFVDQCTFHVANCNFSM4IHNIA2A

.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon

Virus-free.

www.avast.com

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517888623

I removed if/generate, make a common entity file
and separated 2 triggering systems in "tcs" directory
and cleaned up scopeio.vhd
See if this is acceptable for you (before you merge :)
I didn't yet use configuration declaration (must first study some
simple examples) and didn't yet move scopeio_capture, capture1shot, storage to
new tcs directory. I applied minimal changes required for other projects
to be tested does triggering still work after separation.
triggering systems are separated in 2 different glue files:
library/scope/tcs/default/scopeio_trigger_capture_storage.vhd
library/scope/tcs/1shot/scopeio_trigger_capture_storage.vhd
currently, to select triggering system at compile time,
choose either /1shot/ or /default/ glue file
On 8/3/19, D EMARD<EMAIL_ADDRESS>wrote:

Thanks, it seems I never used configuration declaration before,
but I'm slowly starting to understand... :)
I found it is already used in s3estarter and nuhs3adsp
so I can have some code examples too
until I understand it better, I can think of it as
clean replacement for if/generate
To migrate I suggest we do it in steps.
First step - separate files to directories in classical way,
each file set has glue module that fits to the same "component"
library/scopeio/tcs
trigger_capture_storage_component.vhd -- common to both
your "default"
library/scopeio/tcs/default/
trigger_capture_storage.vhd -- glue module for your system
scopeio_tcs_default_trigger.vhd
scopeio_tcs_default_capture_storage.vhd
my "1shot"
library/scopeio/tcs/oneshot/
trigger_capture_storage.vhd -- glue module for my system
scopeio_tcs_1shot_trigger_capture.vhd
scopeio_tcs_1shot_storage.vhd
we have already scopeio_trigger.vhd, it is not a trigger
but just a level comparator so I suggest to rename it to
scopeio_level_comparator.vhd
what do you think
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

On Fri, Aug 2, 2019 at 9:19 PM emard<EMAIL_ADDRESS>wrote:

HI

I think I fixed it to work.

I must first understand what you mean by "interface" (is it port map

namespace?)

Yes  ....

and "configuration declaration" (i'm not sure is it list of files to

compile or something

else in vhdl language different than if/generate?)

It is a VHDL syntax that let you to place different entities on
components

without knowing what is inside of the high level architecture

Something similar to software shared library .... you can replace a
shared

library by yours without knowing what the program that uses it does

meanwhile the specification of the library is compliant

You can think of opengl in linux:  you have Mesa or manufactures owns
one.

In that way, you can add all available trigger systems on the same
library

or external ones and choose whatever entity you want on the component
that

is used without touching or even know what scopeio is about.

Here is a much better explanation ... this is one of reasons why I love

VHDL ... that structure is part of first ever VHDL standard in 1988.

https://www.doulos.com/knowhow/vhdl_designers_guide/configurations_part_1/

I only understand fully that you want if/generate to go away

I want users, all of them, can custom as much as they want without make

scopeio a if itisme gnenerate

:)

1-shot structure of modules is slightly different than your trigger,

I have separate capture and storage module while I have triggering

integrated in the capture.

And I want it to be there ... it is you who understand how it works and

you need it

You have separated triggering but integrated capture and storage.

Do you want me to make trig1shot as compatible port map namespace

and a kind of a glue module that glues capture and storage?

What I want is to try to find a general interface ( as much as it is

possible) that lets your triggers system and mine being chosen using

component on VHDL completly transparent , no preferences. That is the

main goal of *configuration declaration *in VHDL

On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_capture.vhd#L45

there capture_av tells the system when the video address to plot
is

valid.

https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_video.vhd#L69

scopeio_video set that signal.

to disable the trace, you have to set capture_dv to '0' along the

sample

you don't want to show.

https://github.com/hdl4fpga/hdl4fpga/blob/02e197579b319591d05837adf4aef5d52c0a7286/library/scope/scopeio_capture.vhd#L47

_When you make it work we have to agree on an interface, so there is
no

**if

generate if not generate** in scopeio.vhd. Modules will be
selected

by

Configuration Declaration There are other users that want to add

their

trigger systems_

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517867930

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOK3IG7JYLVJBTIVTRTQCTFHVA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PC7UA#issuecomment-517877712,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ACYCMOMD3FVL5IN7AMYIFVDQCTFHVANCNFSM4IHNIA2A

.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon

Virus-free.

www.avast.com

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517888623

Leave as it is now ... let me write a proposal and then suggestions will lead to a specification

OK no problem, I'll backup my stuff
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

Leave as it is now ... let me write a proposal and then suggestions will
lead to a specification
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517921890

What do you think about this ? https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tdc:-Trigger-Downsampling-Capture-specifiacition

link's changed https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tds:-Trigger-Downsampling-Storage-specifiacition

Yes I think that TDS should be glued together
as we can't do clean separation of functions for
triggering, downsampling, capture, storage.
your approach mixes a part of trigger into downsampler
and integrates capture and storage but has a triggering condition
exposed to be user-defined what is nice.
however, negative time storage (before trigger)
with deflickering is IMHO not easily possible once a part of the triggering
is mixed into the downsampler.
my approach integrates simple edge trigger with capture deflickering
because they share so many signals, but has clean downsampler from
any triggering jobs and not too dirty storage. Storage treats special case
of downsampling and does parts of video display jobs like scrolling and
trace visibility therefore although it looks like bloated with junk, we can
consider this "clean" as it must be done by the "spec" :).
My logic is that, if user needs a custom triggering condition he can still write
external module that outputs it to a synthetic channel which is triggered again
on classical way.
I think it's better not to force separation of TDS. It would be
possible, but with
duplicated parts and increased LUT usage, so I'd rather choose integration
than duplicated code and fmax fall down because of more LUTs spent,
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

link's changed
https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tds:-Trigger-Downsampling-Storage-specifiacition
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517956963

Apart from the philosopical blues, I have tried to separate 2
triggering modes and
this entity currently has all that it needs for both:
entity scopeio_trigger_capture_storage is
generic
(
inputs                : natural;
hz_factors            : natural_vector
);
port
(
-- clock domain: incoming samples
input_clk             : in  std_logic;
resizedsample_dv      : in  std_logic;
resizedsample_data    : in  std_logic_vector;
trigger_shot          : in  std_logic; -- TODO: rename to
trigger_level_compare
-- clock domain: GUI (probably any clock domain is acceptable here)
trigger_freeze        : in  std_logic;
hz_scale              : in  std_logic_vector;
hz_slider             : in  std_logic_vector;
-- clock domain: video system pixel clock
video_clk             : in  std_logic;
video_vton            : in  std_logic;
capture_addr          : in  std_logic_vector;
capture_av            : in  std_logic;
capture_dv            : out std_logic;
capture_data          : out std_logic_vector
);
end; -- of entity
On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes I think that TDS should be glued together
as we can't do clean separation of functions for
triggering, downsampling, capture, storage.
your approach mixes a part of trigger into downsampler
and integrates capture and storage but has a triggering condition
exposed to be user-defined what is nice.
however, negative time storage (before trigger)
with deflickering is IMHO not easily possible once a part of the triggering
is mixed into the downsampler.
my approach integrates simple edge trigger with capture deflickering
because they share so many signals, but has clean downsampler from
any triggering jobs and not too dirty storage. Storage treats special case
of downsampling and does parts of video display jobs like scrolling and
trace visibility therefore although it looks like bloated with junk, we can
consider this "clean" as it must be done by the "spec" :).
My logic is that, if user needs a custom triggering condition he can still
write
external module that outputs it to a synthetic channel which is triggered
again
on classical way.
I think it's better not to force separation of TDS. It would be
possible, but with
duplicated parts and increased LUT usage, so I'd rather choose integration
than duplicated code and fmax fall down because of more LUTs spent,
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

link's changed
https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tds:-Trigger-Downsampling-Storage-specifiacition
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517956963

Yes, the TDS should be specified properly and become a "black box"
As the current state with control of trace invisibilty, I'm pretty satisfied
with 1-shot function.
One thing I'd like to have to be able to change timebase at frozen display,
and zoom waveform in time.
I think it should be possible with some intervertion in storage module
and not touching anything else.
What I'd like to is that double samples format would be so reordered
that storage doesn't need to know number of inputs to handle special case:
sample(0 to sample_bits/2-1) = channel0_Ya & channel1_Ya & ... & channelN_Ya
sample(sample_bits/2 to sample_bits-1) = channel0_Yb & channel1_Yb &
... & channelN_Yb
to select Ya or Yb, we only need to split sample in half,
without knowing number of channels, it leads to code shorter and simplified.
On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Apart from the philosopical blues, I have tried to separate 2
triggering modes and
this entity currently has all that it needs for both:
entity scopeio_trigger_capture_storage is
generic
(
inputs                : natural;
hz_factors            : natural_vector
);
port
(
-- clock domain: incoming samples
input_clk             : in  std_logic;
resizedsample_dv      : in  std_logic;
resizedsample_data    : in  std_logic_vector;
trigger_shot          : in  std_logic; -- TODO: rename to
trigger_level_compare
-- clock domain: GUI (probably any clock domain is acceptable here)
trigger_freeze        : in  std_logic;
hz_scale              : in  std_logic_vector;
hz_slider             : in  std_logic_vector;
-- clock domain: video system pixel clock
video_clk             : in  std_logic;
video_vton            : in  std_logic;
capture_addr          : in  std_logic_vector;
capture_av            : in  std_logic;
capture_dv            : out std_logic;
capture_data          : out std_logic_vector
);
end; -- of entity
On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes I think that TDS should be glued together
as we can't do clean separation of functions for
triggering, downsampling, capture, storage.
your approach mixes a part of trigger into downsampler
and integrates capture and storage but has a triggering condition
exposed to be user-defined what is nice.
however, negative time storage (before trigger)
with deflickering is IMHO not easily possible once a part of the
triggering
is mixed into the downsampler.
my approach integrates simple edge trigger with capture deflickering
because they share so many signals, but has clean downsampler from
any triggering jobs and not too dirty storage. Storage treats special
case
of downsampling and does parts of video display jobs like scrolling and
trace visibility therefore although it looks like bloated with junk, we
can
consider this "clean" as it must be done by the "spec" :).
My logic is that, if user needs a custom triggering condition he can
still
write
external module that outputs it to a synthetic channel which is triggered
again
on classical way.
I think it's better not to force separation of TDS. It would be
possible, but with
duplicated parts and increased LUT usage, so I'd rather choose
integration
than duplicated code and fmax fall down because of more LUTs spent,
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

link's changed
https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tds:-Trigger-Downsampling-Storage-specifiacition
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517956963

On Sun, Aug 4, 2019, 09:56 emard<EMAIL_ADDRESS>wrote:

Yes, the TDS should be specified properly and become a "black box"
As the current state with control of trace invisibilty, I'm pretty
satisfied
with 1-shot function.
One thing I'd like to have to be able to change timebase at frozen display,
and zoom waveform in time.
I think it should be possible with some intervertion in storage module
and not touching anything else

i missed very important thing in the specification of tds .... so it is
incomplete hz_scale and hz_slider should be there

What I'd like to is that double samples format would be so reordered
that storage doesn't need to know number of inputs to handle special case:
sample(0 to sample_bits/2-1) = channel0_Ya & channel1_Ya & ... &
channelN_Ya
sample(sample_bits/2 to sample_bits-1) = channel0_Yb & channel1_Yb &
... & channelN_Yb
to select Ya or Yb, we only need to split sample in half,
without knowing number of channels, it leads to code shorter and
simplified.
On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Apart from the philosopical blues, I have tried to separate 2
triggering modes and
this entity currently has all that it needs for both:
entity scopeio_trigger_capture_storage is
generic
(
inputs : natural;
hz_factors : natural_vector
);
port
(
-- clock domain: incoming samples
input_clk : in std_logic;
resizedsample_dv : in std_logic;
resizedsample_data : in std_logic_vector;
trigger_shot : in std_logic; -- TODO: rename to
trigger_level_compare
-- clock domain: GUI (probably any clock domain is acceptable here)
trigger_freeze : in std_logic;
hz_scale : in std_logic_vector;
hz_slider : in std_logic_vector;
-- clock domain: video system pixel clock
video_clk : in std_logic;
video_vton : in std_logic;
capture_addr : in std_logic_vector;
capture_av : in std_logic;
capture_dv : out std_logic;
capture_data : out std_logic_vector
);
end; -- of entity
On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes I think that TDS should be glued together
as we can't do clean separation of functions for
triggering, downsampling, capture, storage.
your approach mixes a part of trigger into downsampler
and integrates capture and storage but has a triggering condition
exposed to be user-defined what is nice.
however, negative time storage (before trigger)
with deflickering is IMHO not easily possible once a part of the
triggering
is mixed into the downsampler.
my approach integrates simple edge trigger with capture deflickering
because they share so many signals, but has clean downsampler from
any triggering jobs and not too dirty storage. Storage treats special
case
of downsampling and does parts of video display jobs like scrolling and
trace visibility therefore although it looks like bloated with junk, we
can
consider this "clean" as it must be done by the "spec" :).
My logic is that, if user needs a custom triggering condition he can
still
write
external module that outputs it to a synthetic channel which is
triggered
again
on classical way.
I think it's better not to force separation of TDS. It would be
possible, but with
duplicated parts and increased LUT usage, so I'd rather choose
integration
than duplicated code and fmax fall down because of more LUTs spent,
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

link's changed

https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tds:-Trigger-Downsampling-Storage-specifiacition

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517956963

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOPWSZG232ZHL6L7SGDQC3GX7A5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QBIPY#issuecomment-518001727,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMOL6B5MJQ7FYD5LEQLLQC3GX7ANCNFSM4IHNIA2A
.

I have already tried this entity I posted, and signal list is ok
it compiled and worked when if/generate code was moved
to separate files.
On 8/5/19, Miguel Angel<EMAIL_ADDRESS>wrote:

On Sun, Aug 4, 2019, 09:56 emard<EMAIL_ADDRESS>wrote:

Yes, the TDS should be specified properly and become a "black box"

As the current state with control of trace invisibilty, I'm pretty

satisfied

with 1-shot function.

One thing I'd like to have to be able to change timebase at frozen
display,

and zoom waveform in time.

I think it should be possible with some intervertion in storage module

and not touching anything else

i missed very important thing in the specification of tds .... so it is

incomplete hz_scale and hz_slider should be there

What I'd like to is that double samples format would be so reordered

that storage doesn't need to know number of inputs to handle special
case:

sample(0 to sample_bits/2-1) = channel0_Ya & channel1_Ya & ... &

channelN_Ya

sample(sample_bits/2 to sample_bits-1) = channel0_Yb & channel1_Yb &

... & channelN_Yb

to select Ya or Yb, we only need to split sample in half,

without knowing number of channels, it leads to code shorter and

simplified.

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Apart from the philosopical blues, I have tried to separate 2

triggering modes and

this entity currently has all that it needs for both:

entity scopeio_trigger_capture_storage is

generic

(

inputs : natural;

hz_factors : natural_vector

);

port

(

-- clock domain: incoming samples

input_clk : in std_logic;

resizedsample_dv : in std_logic;

resizedsample_data : in std_logic_vector;

trigger_shot : in std_logic; -- TODO: rename to

trigger_level_compare

-- clock domain: GUI (probably any clock domain is acceptable here)

trigger_freeze : in std_logic;

hz_scale : in std_logic_vector;

hz_slider : in std_logic_vector;

-- clock domain: video system pixel clock

video_clk : in std_logic;

video_vton : in std_logic;

capture_addr : in std_logic_vector;

capture_av : in std_logic;

capture_dv : out std_logic;

capture_data : out std_logic_vector

);

end; -- of entity

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes I think that TDS should be glued together

as we can't do clean separation of functions for

triggering, downsampling, capture, storage.

your approach mixes a part of trigger into downsampler

and integrates capture and storage but has a triggering condition

exposed to be user-defined what is nice.

however, negative time storage (before trigger)

with deflickering is IMHO not easily possible once a part of the

triggering

is mixed into the downsampler.

my approach integrates simple edge trigger with capture deflickering

because they share so many signals, but has clean downsampler from

any triggering jobs and not too dirty storage. Storage treats special

case

of downsampling and does parts of video display jobs like scrolling
and

trace visibility therefore although it looks like bloated with junk,
we

can

consider this "clean" as it must be done by the "spec" :).

My logic is that, if user needs a custom triggering condition he can

still

write

external module that outputs it to a synthetic channel which is

triggered

again

on classical way.

I think it's better not to force separation of TDS. It would be

possible, but with

duplicated parts and increased LUT usage, so I'd rather choose

integration

than duplicated code and fmax fall down because of more LUTs spent,

On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

link's changed

https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tds:-Trigger-Downsampling-Storage-specifiacition

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517956963

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOPWSZG232ZHL6L7SGDQC3GX7A5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QBIPY#issuecomment-518001727,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ACYCMOL6B5MJQ7FYD5LEQLLQC3GX7ANCNFSM4IHNIA2A

.

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-518099739

On Sun, Aug 4, 2019 at 9:56 AM emard<EMAIL_ADDRESS>wrote:

One thing I'd like to have to be able to change timebase at frozen display,
and zoom waveform in time.

I think it should be possible with some intervertion in storage module

and not touching anything else.

I
think it is possible not easy. Zooming out shouldn't be a problem but
zooming in won't be possible. A post downsampler at the end of the storage
system but at video frequency speed.

What I'd like to is that double samples format would be so reordered
that storage doesn't need to know number of inputs to handle special case:
sample(0 to sample_bits/2-1) = channel0_Ya & channel1_Ya & ... &
channelN_Ya
sample(sample_bits/2 to sample_bits-1) = channel0_Yb & channel1_Yb &
... & channelN_Yb

if I understood well, when does it need to know the number of input
channels ? It is supposed it do not. It should store samples in pairs, no
separates

to select Ya or Yb, we only need to split sample in half,
without knowing number of channels, it leads to code shorter and
simplified.
On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Apart from the philosopical blues, I have tried to separate 2
triggering modes and
this entity currently has all that it needs for both:
entity scopeio_trigger_capture_storage is
generic
(
inputs : natural;
hz_factors : natural_vector
);
port
(
-- clock domain: incoming samples
input_clk : in std_logic;
resizedsample_dv : in std_logic;
resizedsample_data : in std_logic_vector;
trigger_shot : in std_logic; -- TODO: rename to
trigger_level_compare
-- clock domain: GUI (probably any clock domain is acceptable here)
trigger_freeze : in std_logic;
hz_scale : in std_logic_vector;
hz_slider : in std_logic_vector;
-- clock domain: video system pixel clock
video_clk : in std_logic;
video_vton : in std_logic;
capture_addr : in std_logic_vector;
capture_av : in std_logic;
capture_dv : out std_logic;
capture_data : out std_logic_vector
);
end; -- of entity
On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes I think that TDS should be glued together
as we can't do clean separation of functions for
triggering, downsampling, capture, storage.
your approach mixes a part of trigger into downsampler
and integrates capture and storage but has a triggering condition
exposed to be user-defined what is nice.
however, negative time storage (before trigger)
with deflickering is IMHO not easily possible once a part of the
triggering
is mixed into the downsampler.
my approach integrates simple edge trigger with capture deflickering
because they share so many signals, but has clean downsampler from
any triggering jobs and not too dirty storage. Storage treats special
case
of downsampling and does parts of video display jobs like scrolling and
trace visibility therefore although it looks like bloated with junk, we
can
consider this "clean" as it must be done by the "spec" :).
My logic is that, if user needs a custom triggering condition he can
still
write
external module that outputs it to a synthetic channel which is
triggered
again
on classical way.
I think it's better not to force separation of TDS. It would be
possible, but with
duplicated parts and increased LUT usage, so I'd rather choose
integration
than duplicated code and fmax fall down because of more LUTs spent,
On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

link's changed

https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tds:-Trigger-Downsampling-Storage-specifiacition

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517956963

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOPWSZG232ZHL6L7SGDQC3GX7A5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QBIPY#issuecomment-518001727,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMOL6B5MJQ7FYD5LEQLLQC3GX7ANCNFSM4IHNIA2A
.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Libre
de virus. www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

I was thinking only about mangling the addr of the time zoom
well I think power of 2 would be easy in both directions in/out
only other factors might be not worth the hassle. I'd be fine even
with power of 2.
If it doesn't need to know number of samples then it would be
possible to replace cumbersome for/loop with just a
(a to b) range but obviously it isn't currently so, - sample storage format
should be redefined.all N channels first then second their pairs
not channel 0 part A, channel 0 part B etc
On 8/6/19, Miguel Angel<EMAIL_ADDRESS>wrote:

On Sun, Aug 4, 2019 at 9:56 AM emard<EMAIL_ADDRESS>wrote:

One thing I'd like to have to be able to change timebase at frozen
display,

and zoom waveform in time.

I think it should be possible with some intervertion in storage module

and not touching anything else.

I

think it is possible not easy. Zooming out shouldn't be a problem but

zooming in won't be possible. A post downsampler at the end of the storage

system but at video frequency speed.

What I'd like to is that double samples format would be so reordered

that storage doesn't need to know number of inputs to handle special
case:

sample(0 to sample_bits/2-1) = channel0_Ya & channel1_Ya & ... &

channelN_Ya

sample(sample_bits/2 to sample_bits-1) = channel0_Yb & channel1_Yb &

... & channelN_Yb

if I understood well, when does it need to know the number of input

channels ? It is supposed it do not. It should store samples in pairs, no

separates

to select Ya or Yb, we only need to split sample in half,

without knowing number of channels, it leads to code shorter and

simplified.

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Apart from the philosopical blues, I have tried to separate 2

triggering modes and

this entity currently has all that it needs for both:

entity scopeio_trigger_capture_storage is

generic

(

inputs : natural;

hz_factors : natural_vector

);

port

(

-- clock domain: incoming samples

input_clk : in std_logic;

resizedsample_dv : in std_logic;

resizedsample_data : in std_logic_vector;

trigger_shot : in std_logic; -- TODO: rename to

trigger_level_compare

-- clock domain: GUI (probably any clock domain is acceptable here)

trigger_freeze : in std_logic;

hz_scale : in std_logic_vector;

hz_slider : in std_logic_vector;

-- clock domain: video system pixel clock

video_clk : in std_logic;

video_vton : in std_logic;

capture_addr : in std_logic_vector;

capture_av : in std_logic;

capture_dv : out std_logic;

capture_data : out std_logic_vector

);

end; -- of entity

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes I think that TDS should be glued together

as we can't do clean separation of functions for

triggering, downsampling, capture, storage.

your approach mixes a part of trigger into downsampler

and integrates capture and storage but has a triggering condition

exposed to be user-defined what is nice.

however, negative time storage (before trigger)

with deflickering is IMHO not easily possible once a part of the

triggering

is mixed into the downsampler.

my approach integrates simple edge trigger with capture deflickering

because they share so many signals, but has clean downsampler from

any triggering jobs and not too dirty storage. Storage treats special

case

of downsampling and does parts of video display jobs like scrolling
and

trace visibility therefore although it looks like bloated with junk,
we

can

consider this "clean" as it must be done by the "spec" :).

My logic is that, if user needs a custom triggering condition he can

still

write

external module that outputs it to a synthetic channel which is

triggered

again

on classical way.

I think it's better not to force separation of TDS. It would be

possible, but with

duplicated parts and increased LUT usage, so I'd rather choose

integration

than duplicated code and fmax fall down because of more LUTs spent,

On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

link's changed

https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tds:-Trigger-Downsampling-Storage-specifiacition

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517956963

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOPWSZG232ZHL6L7SGDQC3GX7A5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QBIPY#issuecomment-518001727,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ACYCMOL6B5MJQ7FYD5LEQLLQC3GX7ANCNFSM4IHNIA2A

.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

Libre

de virus. www.avast.com

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-518696397

If it doesn't need to know number of samples then it would be
possible to replace cumbersome for/loop with just a
(a to b) range but obviously it isn't currently so, - sample storage format
should be redefined.all N channels first then second their pairs
not channel 0 part A, channel 0 part B etc
I think I'm not following you, why does the storage system need to know
the number of input channels either way ?

On 8/6/19, Miguel Angel<EMAIL_ADDRESS>wrote:

On Sun, Aug 4, 2019 at 9:56 AM emard<EMAIL_ADDRESS>wrote:

One thing I'd like to have to be able to change timebase at frozen
display,

and zoom waveform in time.

I think it should be possible with some intervertion in storage module

and not touching anything else.

I

think it is possible not easy. Zooming out shouldn't be a problem but

zooming in won't be possible. A post downsampler at the end of the
storage

system but at video frequency speed.

What I'd like to is that double samples format would be so reordered

that storage doesn't need to know number of inputs to handle special
case:

sample(0 to sample_bits/2-1) = channel0_Ya & channel1_Ya & ... &

channelN_Ya

sample(sample_bits/2 to sample_bits-1) = channel0_Yb & channel1_Yb &

... & channelN_Yb

if I understood well, when does it need to know the number of input

channels ? It is supposed it do not. It should store samples in pairs, no

separates

to select Ya or Yb, we only need to split sample in half,

without knowing number of channels, it leads to code shorter and

simplified.

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Apart from the philosopical blues, I have tried to separate 2

triggering modes and

this entity currently has all that it needs for both:

entity scopeio_trigger_capture_storage is

generic

(

inputs : natural;

hz_factors : natural_vector

);

port

(

-- clock domain: incoming samples

input_clk : in std_logic;

resizedsample_dv : in std_logic;

resizedsample_data : in std_logic_vector;

trigger_shot : in std_logic; -- TODO: rename to

trigger_level_compare

-- clock domain: GUI (probably any clock domain is acceptable here)

trigger_freeze : in std_logic;

hz_scale : in std_logic_vector;

hz_slider : in std_logic_vector;

-- clock domain: video system pixel clock

video_clk : in std_logic;

video_vton : in std_logic;

capture_addr : in std_logic_vector;

capture_av : in std_logic;

capture_dv : out std_logic;

capture_data : out std_logic_vector

);

end; -- of entity

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes I think that TDS should be glued together

as we can't do clean separation of functions for

triggering, downsampling, capture, storage.

your approach mixes a part of trigger into downsampler

and integrates capture and storage but has a triggering condition

exposed to be user-defined what is nice.

however, negative time storage (before trigger)

with deflickering is IMHO not easily possible once a part of the

triggering

is mixed into the downsampler.

my approach integrates simple edge trigger with capture deflickering

because they share so many signals, but has clean downsampler from

any triggering jobs and not too dirty storage. Storage treats special

case

of downsampling and does parts of video display jobs like scrolling
and

trace visibility therefore although it looks like bloated with junk,
we

can

consider this "clean" as it must be done by the "spec" :).

My logic is that, if user needs a custom triggering condition he can

still

write

external module that outputs it to a synthetic channel which is

triggered

again

on classical way.

I think it's better not to force separation of TDS. It would be

possible, but with

duplicated parts and increased LUT usage, so I'd rather choose

integration

than duplicated code and fmax fall down because of more LUTs spent,

On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

link's changed

https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tds:-Trigger-Downsampling-Storage-specifiacition

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517956963

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

<
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOPWSZG232ZHL6L7SGDQC3GX7A5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QBIPY#issuecomment-518001727
,

or mute the thread

<
https://github.com/notifications/unsubscribe-auth/ACYCMOL6B5MJQ7FYD5LEQLLQC3GX7ANCNFSM4IHNIA2A

.

<
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

Libre

de virus. www.avast.com

<
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-518696397

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOKUR2FT454EL6UOK2TQDGLRZA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VSB6Q#issuecomment-518725882,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMOO42RR3SJXHTSQIUHLQDGLRZANCNFSM4IHNIA2A
.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Libre
de virus. www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Storage system needs to treat special case of downsampling = 0
buffer is double lenght and for this case, storage system when it
provides data to video system, it reshuffles
the samples mixing them with the samples from previous
query in order for display to shows proper waveform in the spacial case
of downsampling = 0
for this to work, currently number of channels and bits per channels should
be known. Only the number of channels is passed because bits per channel
can be calculated from sample size
treating this special case is nightmare :)
On 8/6/19, Miguel Angel<EMAIL_ADDRESS>wrote:

If it doesn't need to know number of samples then it would be

possible to replace cumbersome for/loop with just a

(a to b) range but obviously it isn't currently so, - sample storage
format

should be redefined.all N channels first then second their pairs

not channel 0 part A, channel 0 part B etc

I think I'm not following you, why does the storage system need to know

the number of input channels either way ?

On 8/6/19, Miguel Angel<EMAIL_ADDRESS>wrote:

On Sun, Aug 4, 2019 at 9:56 AM emard<EMAIL_ADDRESS>wrote:

One thing I'd like to have to be able to change timebase at frozen

display,

and zoom waveform in time.

I think it should be possible with some intervertion in storage module

and not touching anything else.

I

think it is possible not easy. Zooming out shouldn't be a problem but

zooming in won't be possible. A post downsampler at the end of the

storage

system but at video frequency speed.

What I'd like to is that double samples format would be so reordered

that storage doesn't need to know number of inputs to handle special

case:

sample(0 to sample_bits/2-1) = channel0_Ya & channel1_Ya & ... &

channelN_Ya

sample(sample_bits/2 to sample_bits-1) = channel0_Yb & channel1_Yb &

... & channelN_Yb

if I understood well, when does it need to know the number of input

channels ? It is supposed it do not. It should store samples in pairs,
no

separates

to select Ya or Yb, we only need to split sample in half,

without knowing number of channels, it leads to code shorter and

simplified.

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Apart from the philosopical blues, I have tried to separate 2

triggering modes and

this entity currently has all that it needs for both:

entity scopeio_trigger_capture_storage is

generic

(

inputs : natural;

hz_factors : natural_vector

);

port

(

-- clock domain: incoming samples

input_clk : in std_logic;

resizedsample_dv : in std_logic;

resizedsample_data : in std_logic_vector;

trigger_shot : in std_logic; -- TODO: rename to

trigger_level_compare

-- clock domain: GUI (probably any clock domain is acceptable here)

trigger_freeze : in std_logic;

hz_scale : in std_logic_vector;

hz_slider : in std_logic_vector;

-- clock domain: video system pixel clock

video_clk : in std_logic;

video_vton : in std_logic;

capture_addr : in std_logic_vector;

capture_av : in std_logic;

capture_dv : out std_logic;

capture_data : out std_logic_vector

);

end; -- of entity

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes I think that TDS should be glued together

as we can't do clean separation of functions for

triggering, downsampling, capture, storage.

your approach mixes a part of trigger into downsampler

and integrates capture and storage but has a triggering condition

exposed to be user-defined what is nice.

however, negative time storage (before trigger)

with deflickering is IMHO not easily possible once a part of the

triggering

is mixed into the downsampler.

my approach integrates simple edge trigger with capture
deflickering

because they share so many signals, but has clean downsampler from

any triggering jobs and not too dirty storage. Storage treats
special

case

of downsampling and does parts of video display jobs like
scrolling

and

trace visibility therefore although it looks like bloated with
junk,

we

can

consider this "clean" as it must be done by the "spec" :).

My logic is that, if user needs a custom triggering condition he
can

still

write

external module that outputs it to a synthetic channel which is

triggered

again

on classical way.

I think it's better not to force separation of TDS. It would be

possible, but with

duplicated parts and increased LUT usage, so I'd rather choose

integration

than duplicated code and fmax fall down because of more LUTs
spent,

On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

link's changed

https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tds:-Trigger-Downsampling-Storage-specifiacition

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517956963

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

<

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOPWSZG232ZHL6L7SGDQC3GX7A5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QBIPY#issuecomment-518001727

,

or mute the thread

<

https://github.com/notifications/unsubscribe-auth/ACYCMOL6B5MJQ7FYD5LEQLLQC3GX7ANCNFSM4IHNIA2A

.

<

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

Libre

de virus. www.avast.com

<

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-518696397

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOKUR2FT454EL6UOK2TQDGLRZA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VSB6Q#issuecomment-518725882,

or mute the thread

https://github.com/notifications/unsubscribe-auth/ACYCMOO42RR3SJXHTSQIUHLQDGLRZANCNFSM4IHNIA2A

.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

Libre

de virus. www.avast.com

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-518733584

Why does it not possible to reshuffle at the end of the storage system ?.
The reshuffling have to be done  either way and it is better done previous
the video system.
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Libre
de virus. www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Tue, Aug 6, 2019 at 1:50 PM emard<EMAIL_ADDRESS>wrote:

Storage system needs to treat special case of downsampling = 0
buffer is double lenght and for this case, storage system when it
provides data to video system, it reshuffles
the samples mixing them with the samples from previous
query in order for display to shows proper waveform in the spacial case
of downsampling = 0
for this to work, currently number of channels and bits per channels should
be known. Only the number of channels is passed because bits per channel
can be calculated from sample size
treating this special case is nightmare :)
On 8/6/19, Miguel Angel<EMAIL_ADDRESS>wrote:

If it doesn't need to know number of samples then it would be

possible to replace cumbersome for/loop with just a

(a to b) range but obviously it isn't currently so, - sample storage
format

should be redefined.all N channels first then second their pairs

not channel 0 part A, channel 0 part B etc

I think I'm not following you, why does the storage system need to know

the number of input channels either way ?

On 8/6/19, Miguel Angel<EMAIL_ADDRESS>wrote:

On Sun, Aug 4, 2019 at 9:56 AM emard<EMAIL_ADDRESS>wrote:

One thing I'd like to have to be able to change timebase at frozen

display,

and zoom waveform in time.

I think it should be possible with some intervertion in storage module

and not touching anything else.

I

think it is possible not easy. Zooming out shouldn't be a problem but

zooming in won't be possible. A post downsampler at the end of the

storage

system but at video frequency speed.

What I'd like to is that double samples format would be so reordered

that storage doesn't need to know number of inputs to handle special

case:

sample(0 to sample_bits/2-1) = channel0_Ya & channel1_Ya & ... &

channelN_Ya

sample(sample_bits/2 to sample_bits-1) = channel0_Yb & channel1_Yb &

... & channelN_Yb

if I understood well, when does it need to know the number of input

channels ? It is supposed it do not. It should store samples in pairs,
no

separates

to select Ya or Yb, we only need to split sample in half,

without knowing number of channels, it leads to code shorter and

simplified.

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Apart from the philosopical blues, I have tried to separate 2

triggering modes and

this entity currently has all that it needs for both:

entity scopeio_trigger_capture_storage is

generic

(

inputs : natural;

hz_factors : natural_vector

);

port

(

-- clock domain: incoming samples

input_clk : in std_logic;

resizedsample_dv : in std_logic;

resizedsample_data : in std_logic_vector;

trigger_shot : in std_logic; -- TODO: rename to

trigger_level_compare

-- clock domain: GUI (probably any clock domain is acceptable here)

trigger_freeze : in std_logic;

hz_scale : in std_logic_vector;

hz_slider : in std_logic_vector;

-- clock domain: video system pixel clock

video_clk : in std_logic;

video_vton : in std_logic;

capture_addr : in std_logic_vector;

capture_av : in std_logic;

capture_dv : out std_logic;

capture_data : out std_logic_vector

);

end; -- of entity

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes I think that TDS should be glued together

as we can't do clean separation of functions for

triggering, downsampling, capture, storage.

your approach mixes a part of trigger into downsampler

and integrates capture and storage but has a triggering condition

exposed to be user-defined what is nice.

however, negative time storage (before trigger)

with deflickering is IMHO not easily possible once a part of the

triggering

is mixed into the downsampler.

my approach integrates simple edge trigger with capture
deflickering

because they share so many signals, but has clean downsampler from

any triggering jobs and not too dirty storage. Storage treats
special

case

of downsampling and does parts of video display jobs like
scrolling

and

trace visibility therefore although it looks like bloated with
junk,

we

can

consider this "clean" as it must be done by the "spec" :).

My logic is that, if user needs a custom triggering condition he
can

still

write

external module that outputs it to a synthetic channel which is

triggered

again

on classical way.

I think it's better not to force separation of TDS. It would be

possible, but with

duplicated parts and increased LUT usage, so I'd rather choose

integration

than duplicated code and fmax fall down because of more LUTs
spent,

On 8/3/19, Miguel Angel<EMAIL_ADDRESS>wrote:

link's changed

https://github.com/hdl4fpga/hdl4fpga/wiki/scopeio_tds:-Trigger-Downsampling-Storage-specifiacition

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-517956963

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

<

https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOPWSZG232ZHL6L7SGDQC3GX7A5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QBIPY#issuecomment-518001727

,

or mute the thread

<

https://github.com/notifications/unsubscribe-auth/ACYCMOL6B5MJQ7FYD5LEQLLQC3GX7ANCNFSM4IHNIA2A

.

<

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

Libre

de virus. www.avast.com

<

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-518696397

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub

<
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOKUR2FT454EL6UOK2TQDGLRZA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VSB6Q#issuecomment-518725882
,

or mute the thread

<
https://github.com/notifications/unsubscribe-auth/ACYCMOO42RR3SJXHTSQIUHLQDGLRZANCNFSM4IHNIA2A

.

<
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

Libre

de virus. www.avast.com

<
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--

You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub:

https://github.com/hdl4fpga/hdl4fpga/issues/165#issuecomment-518733584

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hdl4fpga/hdl4fpga/issues/165?email_source=notifications&email_token=ACYCMOLRRMYZAUKDZRKGGM3QDGTUHA5CNFSM4IHNIA2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3VYSMI#issuecomment-518752561,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYCMONWF4OKVQOZKMROW7LQDGTUHANCNFSM4IHNIA2A
.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Libre
de virus. www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

to better illustrage the situation, I shall probably write a
pre-shuffler and post-shuffer before and after the storage module
to let inside be more readable... but anyway
I have a good news, while experimenting with usb-serial module
I replaced the usb-serial descriptor with usb-network, and got linux
to recognize it as network device and something appears to work!
I wrote a simple ping echo reply core, it can responds to raw pings with
up to 1000 packets/s and have cca 6% packet loss, mainly because it doesn't know
how to handle fragmented packets when rxvalid sometimes falls in the
middle of the frame
On 8/6/19, Miguel Angel<EMAIL_ADDRESS>wrote:

Why does it not possible to reshuffle at the end of the storage system ?.

The reshuffling have to be done  either way and it is better done previous

the video system.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

Libre

de virus. www.avast.com

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Aug 6, 2019 at 1:50 PM emard<EMAIL_ADDRESS>wrote:

Storage system needs to treat special case of downsampling = 0

buffer is double lenght and for this case, storage system when it

provides data to video system, it reshuffles

the samples mixing them with the samples from previous

query in order for display to shows proper waveform in the spacial case

of downsampling = 0

for this to work, currently number of channels and bits per channels
should

be known. Only the number of channels is passed because bits per channel

can be calculated from sample size

treating this special case is nightmare :)

On 8/6/19, Miguel Angel<EMAIL_ADDRESS>wrote:

If it doesn't need to know number of samples then it would be

possible to replace cumbersome for/loop with just a

(a to b) range but obviously it isn't currently so, - sample storage

format

should be redefined.all N channels first then second their pairs

not channel 0 part A, channel 0 part B etc

I think I'm not following you, why does the storage system need to
know

the number of input channels either way ?

On 8/6/19, Miguel Angel<EMAIL_ADDRESS>wrote:

On Sun, Aug 4, 2019 at 9:56 AM emard<EMAIL_ADDRESS>

wrote:

One thing I'd like to have to be able to change timebase at frozen

display,

and zoom waveform in time.

I think it should be possible with some intervertion in storage
module

and not touching anything else.

I

think it is possible not easy. Zooming out shouldn't be a problem
but

zooming in won't be possible. A post downsampler at the end of the

storage

system but at video frequency speed.

What I'd like to is that double samples format would be so
reordered

that storage doesn't need to know number of inputs to handle
special

case:

sample(0 to sample_bits/2-1) = channel0_Ya & channel1_Ya & ... &

channelN_Ya

sample(sample_bits/2 to sample_bits-1) = channel0_Yb & channel1_Yb
&

... & channelN_Yb

if I understood well, when does it need to know the number of input

channels ? It is supposed it do not. It should store samples in
pairs,

no

separates

to select Ya or Yb, we only need to split sample in half,

without knowing number of channels, it leads to code shorter and

simplified.

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Apart from the philosopical blues, I have tried to separate 2

triggering modes and

this entity currently has all that it needs for both:

entity scopeio_trigger_capture_storage is

generic

(

inputs : natural;

hz_factors : natural_vector

);

port

(

-- clock domain: incoming samples

input_clk : in std_logic;

resizedsample_dv : in std_logic;

resizedsample_data : in std_logic_vector;

trigger_shot : in std_logic; -- TODO: rename to

trigger_level_compare

-- clock domain: GUI (probably any clock domain is acceptable
here)

trigger_freeze : in std_logic;

hz_scale : in std_logic_vector;

hz_slider : in std_logic_vector;

-- clock domain: video system pixel clock

video_clk : in std_logic;

video_vton : in std_logic;

capture_addr : in std_logic_vector;

capture_av : in std_logic;

capture_dv : out std_logic;

capture_data : out std_logic_vector

);

end; -- of entity

On 8/4/19, D EMARD<EMAIL_ADDRESS>wrote:

Yes I think that TDS should be glued together

as we can't do clean separation of functions for

triggering, downsampling, capture, storage.

your approach mixes a part of trigger into downsampler

and integrates capture and storage but has a triggering
condition

exposed to be user-defined what is nice.

however, negative time storage (before trigger)

with deflickering is IMHO not easily possible once a part of
the

triggering

is mixed into the downsampler.

my approach integrates simple edge trigger with capture

deflickering

because they share so many signals, but has clean downsampler
from

any triggering jobs and not too dirty storage. Storage treats

special

case

of downsampling and does parts of video display jobs like

scrolling

and

trace visibility therefore although it looks like bloated with

junk,

we

can

consider this "clean" as it must be done by the "spec" :).

My logic is that, if user needs a custom triggering condition
he

can

still

write

external module that outputs it to a synthetic channel which is