Pulsetrain generation with Verilog
$begingroup$
I'm working with a PSoC device using Cypress' turnkey toolchain, trying to generate a stream of pulses at intervals fed by the microntroller. I've given up trying to do this by drawing gates with the GUI and am writing my second Verilog program ever.
The spec is: pulses are described by a sequence of bytes; if the byte is 0x00..0x7f then wait that many ticks before generating the pulse; is 0x80 then wait 128 ticks and don't generate a pulse. On each pulse, we trigger an interrupt which loads the next byte into the generator.
This should be trivial, but it's behaving really weird...
module Sequencer (
output reg interrupt, // causes data to be updated
output reg wdata, // goes to my consumer
input clock, // tick counter
input [7:0] data, // describes the current pulse
input reset // what it says on the tin
);
reg [6:0] counter;
always @(posedge clock)
begin
if (reset)
begin
counter <= 0;
interrupt <= 0;
wdata <= 0;
end
else
begin
// This matches both pulses (00-7f) and spaces (80).
// For a space, the counter will roll over back to zero.
if (counter == data[6:0])
begin
counter <= 0;
interrupt <= 1;
wdata <= ~data[7]; // 0x80 means no pulse
end
else
begin
counter <= counter + 7'b1;
interrupt <= 0;
wdata <= 0;
end
end
end
endmodule
So, all the logic happens on the rising edge of the tick clock; my outputs are registered so they remain valid until the next rising edge, when I explicitly update them; my two outputs and the temporary counter are updated exactly once through every code path, so avoiding latches...
But what actually happens is that it works fine if my data bytes are in the 0x00-0x7f range, but as soon as I try to use 0x80 bytes, I get garbage out. (Although it's hard to tell as my only way of testing is to record the pulses onto magnetic media, play them back, and sample with my first Verilog program ever...)
I feel that I'm just doing this wrong. So, what's wrong?
verilog
asked 4 hours ago
David GivenDavid Given
99
New contributor
David Given is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
add a comment |
$begingroup$
I'm working with a PSoC device using Cypress' turnkey toolchain, trying to generate a stream of pulses at intervals fed by the microntroller. I've given up trying to do this by drawing gates with the GUI and am writing my second Verilog program ever.
The spec is: pulses are described by a sequence of bytes; if the byte is 0x00..0x7f then wait that many ticks before generating the pulse; is 0x80 then wait 128 ticks and don't generate a pulse. On each pulse, we trigger an interrupt which loads the next byte into the generator.
This should be trivial, but it's behaving really weird...
module Sequencer (
output reg interrupt, // causes data to be updated
output reg wdata, // goes to my consumer
input clock, // tick counter
input [7:0] data, // describes the current pulse
input reset // what it says on the tin
);
reg [6:0] counter;
always @(posedge clock)
begin
if (reset)
begin
counter <= 0;
interrupt <= 0;
wdata <= 0;
end
else
begin
// This matches both pulses (00-7f) and spaces (80).
// For a space, the counter will roll over back to zero.
if (counter == data[6:0])
begin
counter <= 0;
interrupt <= 1;
wdata <= ~data[7]; // 0x80 means no pulse
end
else
begin
counter <= counter + 7'b1;
interrupt <= 0;
wdata <= 0;
end
end
end
endmodule
So, all the logic happens on the rising edge of the tick clock; my outputs are registered so they remain valid until the next rising edge, when I explicitly update them; my two outputs and the temporary counter are updated exactly once through every code path, so avoiding latches...
But what actually happens is that it works fine if my data bytes are in the 0x00-0x7f range, but as soon as I try to use 0x80 bytes, I get garbage out. (Although it's hard to tell as my only way of testing is to record the pulses onto magnetic media, play them back, and sample with my first Verilog program ever...)
I feel that I'm just doing this wrong. So, what's wrong?
verilog
asked 4 hours ago
David GivenDavid Given
99
New contributor
David Given is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
$begingroup$
The code containing the known problem is explicitly off-topic on this exchange. VTC. That said, comparing just 7 bits ofdatafeels weird (initially thecounteris 0, and its 7 bits do match 7 bits of 0x80 immediately, so you assert interrupt at the very first edge instead of waiting 128 ticks).
$endgroup$
– vnp
4 hours ago
add a comment |
$begingroup$
I'm working with a PSoC device using Cypress' turnkey toolchain, trying to generate a stream of pulses at intervals fed by the microntroller. I've given up trying to do this by drawing gates with the GUI and am writing my second Verilog program ever.
The spec is: pulses are described by a sequence of bytes; if the byte is 0x00..0x7f then wait that many ticks before generating the pulse; is 0x80 then wait 128 ticks and don't generate a pulse. On each pulse, we trigger an interrupt which loads the next byte into the generator.
This should be trivial, but it's behaving really weird...
module Sequencer (
output reg interrupt, // causes data to be updated
output reg wdata, // goes to my consumer
input clock, // tick counter
input [7:0] data, // describes the current pulse
input reset // what it says on the tin
);
reg [6:0] counter;
always @(posedge clock)
begin
if (reset)
begin
counter <= 0;
interrupt <= 0;
wdata <= 0;
end
else
begin
// This matches both pulses (00-7f) and spaces (80).
// For a space, the counter will roll over back to zero.
if (counter == data[6:0])
begin
counter <= 0;
interrupt <= 1;
wdata <= ~data[7]; // 0x80 means no pulse
end
else
begin
counter <= counter + 7'b1;
interrupt <= 0;
wdata <= 0;
end
end
end
endmodule
So, all the logic happens on the rising edge of the tick clock; my outputs are registered so they remain valid until the next rising edge, when I explicitly update them; my two outputs and the temporary counter are updated exactly once through every code path, so avoiding latches...
But what actually happens is that it works fine if my data bytes are in the 0x00-0x7f range, but as soon as I try to use 0x80 bytes, I get garbage out. (Although it's hard to tell as my only way of testing is to record the pulses onto magnetic media, play them back, and sample with my first Verilog program ever...)
I feel that I'm just doing this wrong. So, what's wrong?
verilog
asked 4 hours ago
David GivenDavid Given
99
New contributor
David Given is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
I'm working with a PSoC device using Cypress' turnkey toolchain, trying to generate a stream of pulses at intervals fed by the microntroller. I've given up trying to do this by drawing gates with the GUI and am writing my second Verilog program ever.
The spec is: pulses are described by a sequence of bytes; if the byte is 0x00..0x7f then wait that many ticks before generating the pulse; is 0x80 then wait 128 ticks and don't generate a pulse. On each pulse, we trigger an interrupt which loads the next byte into the generator.
This should be trivial, but it's behaving really weird...
module Sequencer (
output reg interrupt, // causes data to be updated
output reg wdata, // goes to my consumer
input clock, // tick counter
input [7:0] data, // describes the current pulse
input reset // what it says on the tin
);
reg [6:0] counter;
always @(posedge clock)
begin
if (reset)
begin
counter <= 0;
interrupt <= 0;
wdata <= 0;
end
else
begin
// This matches both pulses (00-7f) and spaces (80).
// For a space, the counter will roll over back to zero.
if (counter == data[6:0])
begin
counter <= 0;
interrupt <= 1;
wdata <= ~data[7]; // 0x80 means no pulse
end
else
begin
counter <= counter + 7'b1;
interrupt <= 0;
wdata <= 0;
end
end
end
endmodule
So, all the logic happens on the rising edge of the tick clock; my outputs are registered so they remain valid until the next rising edge, when I explicitly update them; my two outputs and the temporary counter are updated exactly once through every code path, so avoiding latches...
But what actually happens is that it works fine if my data bytes are in the 0x00-0x7f range, but as soon as I try to use 0x80 bytes, I get garbage out. (Although it's hard to tell as my only way of testing is to record the pulses onto magnetic media, play them back, and sample with my first Verilog program ever...)
I feel that I'm just doing this wrong. So, what's wrong?
verilog
verilog
asked 4 hours ago
David GivenDavid Given
99
New contributor
David Given is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 4 hours ago
David GivenDavid Given
99
New contributor
David Given is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 4 hours ago
David GivenDavid Given
99
New contributor
David Given is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 4 hours ago
David GivenDavid Given
99
asked 4 hours ago
David GivenDavid Given
99
99
New contributor
David Given is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
David Given is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
David Given is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$begingroup$
The code containing the known problem is explicitly off-topic on this exchange. VTC. That said, comparing just 7 bits ofdatafeels weird (initially thecounteris 0, and its 7 bits do match 7 bits of 0x80 immediately, so you assert interrupt at the very first edge instead of waiting 128 ticks).
$endgroup$
– vnp
4 hours ago
add a comment |
$begingroup$
The code containing the known problem is explicitly off-topic on this exchange. VTC. That said, comparing just 7 bits ofdatafeels weird (initially thecounteris 0, and its 7 bits do match 7 bits of 0x80 immediately, so you assert interrupt at the very first edge instead of waiting 128 ticks).
$endgroup$
– vnp
4 hours ago
$begingroup$
The code containing the known problem is explicitly off-topic on this exchange. VTC. That said, comparing just 7 bits of
data feels weird (initially the counter is 0, and its 7 bits do match 7 bits of 0x80 immediately, so you assert interrupt at the very first edge instead of waiting 128 ticks).$endgroup$
– vnp
4 hours ago
$begingroup$
The code containing the known problem is explicitly off-topic on this exchange. VTC. That said, comparing just 7 bits of
data feels weird (initially the counter is 0, and its 7 bits do match 7 bits of 0x80 immediately, so you assert interrupt at the very first edge instead of waiting 128 ticks).$endgroup$
– vnp
4 hours ago
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
David Given is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f214081%2fpulsetrain-generation-with-verilog%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
David Given is a new contributor. Be nice, and check out our Code of Conduct.
David Given is a new contributor. Be nice, and check out our Code of Conduct.
David Given is a new contributor. Be nice, and check out our Code of Conduct.
David Given is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f214081%2fpulsetrain-generation-with-verilog%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
The code containing the known problem is explicitly off-topic on this exchange. VTC. That said, comparing just 7 bits of
datafeels weird (initially thecounteris 0, and its 7 bits do match 7 bits of 0x80 immediately, so you assert interrupt at the very first edge instead of waiting 128 ticks).$endgroup$
– vnp
4 hours ago