Best way to test Verilog and/or UDB component?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hi,

I wonder if there's a "best practice" to test self-made components. Of course, if a component works as intended for the project it's made for, this is a good result. But in my opinion this is not enough, because in the next project where the component is used there might be other circumstances. So, how do you test your components?

For example, for input signals (either hardware or API controlled), I set the input signals (in case of hardware by control register), and the component clock is controlled also by a control register, not bus clock or similar (if there are input strobes, the clock is not generated synchronously to them, but after settings them). For output signals, if there's a strobe or ready output, I use sticky status registers with the strobe/ready signal as clock.

The corresponding test firmware stimulates all "useful" (not neccessarily possible) input combinations, verifies the outputs against the expected results and outputs errors on UART. But I don't know if this is testing enough. And I've to admit that each test firmware tries to use the same approach, but I always end up with "special" code for a given component - I always feel that my test approach is not abstracted enough.

Currently, I don't use external instruments like logic analyzer or pattern generator to verify the behaviour of a component. I know there's an chapter in the component author guide about simulating components, but this is totally outside of my knowledge. So, are you testing components with external instruments or simulation?

Regards

0 Likes
1 Solution
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Hi,

I too do not have a pattern generator.  I commonly use another PSoC to generate the input signal if possible.

For example, for a project that involved creating a Manchester signal DECODER, I created a Manchester signal ENCODER with a PSoC and fed that signal into the DECODER.  If you have the resources available on the PSoC you're coding for, you can stick the input generator on the same PSoC.

Hope this helps.

Len

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

0 Likes
3 Replies
Vison_Zhang
Moderator
Moderator
Moderator
First comment on KBA 750 replies posted 250 sign-ins

I think the official UDB based components provided in Creator IDE are tested use third-party simulation tools.

To myself, i usually make some special timing modules use verilog, the logic is simple, so i choose to use external instruments for module logic testing.

0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Hi,

I too do not have a pattern generator.  I commonly use another PSoC to generate the input signal if possible.

For example, for a project that involved creating a Manchester signal DECODER, I created a Manchester signal ENCODER with a PSoC and fed that signal into the DECODER.  If you have the resources available on the PSoC you're coding for, you can stick the input generator on the same PSoC.

Hope this helps.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Hello Len & VisonZ_71,

thank you for your answers. So, it seems that my approach is not far away from yours.

Regards

0 Likes